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1.  INTRODUCTION 


The  purpose  of  this  report  is  to  describe  the  output  and  error  diagnostics  generated  by  the 
Army  Unit  Resiliency  Anaiysis  (AURA)  computer  simuiation  model. 

It  is  assumed  that  the  reader  is  reasonably  familiar  with  the  AURA  family  of  methodologies 
and  with  the  purpose  and  function  of  the  many  options  of  the  AURA  model  itself.  The  novice 
AURA  analyst  is  referred  to  the  AURA  Programmer/Analyst  Guides  (Sheroke  1990a,  1990b) 
and  the  AURA  Input  Manual  (Klopcic,  Sheroke.  and  Price  1990)  for  a  comprehensive 
explanation  of  the  methodologies  and  capabilities  of  the  AURA  model. 

The  data  produced  by  AURA  provides  the  analyst  with  the  ability  to  examine,  in  great 
detail,  the  performance  capabilih'  and  status  of  unit  operations  over  a  specified  time  period 
including  the  effectiveness  (as  well  as  degradation)  of  all  unit  equipment  and  personnel. 

AURA  output  data  is  organized  in  a  manner  to  enable  the  analyst  to  examine  the  scenario 
modeled  ranging  from  consolidation  of  inputs  to  ttie  final  (averaged)  effectiveness  and 
casualty  results.  The  initial  section  of  an  AURA  output  consists  of  input  consolidation  in  which 
the  commands,  events,  assets,  and  unit  deployment  are  organized  into  table  form  to  allow  the 
analyst  to  reference  the  initial  conditions  during  the  trial.  The  second  section  of  output  reports 
information  such  as  weapon  impact  points,  casualties,  nuclear  or  chemical  dosages,  and 
degradation  status  at  specified  times  during  the  scenario.  The  third  section  of  output 
illustrates  the  results,  summarizing  each  replication  of  the  AURA  encounter.  Reported  in  the 
third  section  is  unit  effectiveness,  surviving  assets  (including  degradation  due  to  fatigue  or 
contamination),  job  status,  and  mission  results.  This  section  consists  of  the  summarized 
results  which  have  been  averaged  over  all  replications.  The  final  unit  effectiveness  result, 
AURA’S  primary  fruition,  is  reported  in  this  section.  Finally,  the  user  may  optionally  request  to 
include  a  copy  of  the  weapon  effects  data  file  used  in  the  study,  which  will  be  the  last  item 
printed  to  the  AURA  output  file.  Weapon  effects  data  files  describe  the  characteristics 
inherent  to  the  scenario  modeled.  The  types  of  weapon  effects  files  are  nuclear  vulnerability, 
conventional  lethality,  and  chemical  dissemination  and  are  described  in  Appendix  B  of 
Volume  2  (Sheroke  et  al.  1990a). 
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The  information  provided  by  each  output  table  is  generally  specific  to  a  particular  AURA 
methodology.  For  example,  when  playing  a  nuclear  scenario,  the  outputs  relating  to  the 
effects  of  the  nuclear  warhead  are  reported.  Typically  in  an  AURA  analysis,  the  analyst  must 
correlate  the  data  from  several  output  tables  in  order  to  answer  specific  questions  or  further 
understand  the  circumstances  leading  to  the  final  result  values.  This  process,  known  as 
cross-referencing,  is  a  common  analytical  tool  employed  by  the  AURA  analyst.  For  example, 
suppose  the  unit  effectiveness  value  is  shown  to  degrade  from  95%  to  60%  between  the  first 
2  hours  of  a  chemical  scenario.  The  reason  (s)  for  the  degradation  can  be  determined  by 
investigating  the  data  provided  by  the  output  tables  of  the  intermediate  results  section.  A 
possible  reason  for  the  unit’s  degraded  capability  may  be  due  to  the  time  taken  by  personnel 
to  realize  and  react  to  the  detonation  of  a  chemical  munition.  By  varying  AURA  input 
parameters,  the  analyst  can  model  the  reaction  time  which  is  eminent  in  such  a  scenario.  In 
this  case,  the  analyst  can  reference  the  Weapon  Reliability  Table  to  gain  insight  into 
detonation  time,  range  of  the  weapon  effects,  and  targeting  parameters  associated  with  this 
munition.  Another  possible  cause  for  unit  degradation  could  be  a  result  of  the  effects  of  a 
chemical  attack  such  as  contamination  or  hindrance  due  to  wearing  mission-oriented 
protective  posture  (MOPP)  gear.  The  effects  of  these  phenomena  will  invariably  cause  a 
reduction  in  the  unit’s  effective  capability  and  are  described  in  the  Toxic  Dose  Table  and  the 
Degradation  by  MOPP  (and  Toxic  Kill  Criteria  [T  K.C.])  Table,  respectively.  One  of  the  most 
common  factors  in  limiting  the  unit’s  effective  capability  is  the  degradation  or  absence  (i.e., 
casualty)  of  mission-essential  assets.  By  the  usage  of  user-controlled  output  commands, 
AURA  will  report  the  role  and  status  of  each  asset  at  user-specified  reporting  times  within  the 
scenario.  With  this  information,  the  analyst  can  determine  which  assets  or  tasks  have  the 
greatest  impact  upon  the  unit’s  effective  capability  to  perform  its  mission. 

Finally,  the  Appendix  contains  warning  and  error  diagnostics  and  provides  assistance  with 
error  correction  and  debugging.  This  section  includes  suggestions  and  recommended 
solutions  corresponding  to  each  potential  warning  diagnostic  and  error  message  produced  by 
AURA. 
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2.  ORGANIZATION  AND  CONTROL  OF  OUTPUT 


2.1  General  Sequence  of  Output  Tables.  Analyses  involving  the  AURA  methodology  can 
generate  prohibitively  large  amounts  of  various  kinds  of  data.  It  is  possible,  for  example,  to 
print  out  the  impact  point  of  every  incoming  round.  For  100  replications  of  a  study  involving  a 
heavy  artillery  barrage,  the  impact  point  output  alone  could  consume  upwards  of  10,000 
pages  of  computer  paper.  For  this  reason.  AURA  is  equipped  with  output  options  which  allow 
the  user  to  select  the  scenario-dependent  entities  to  be  printed.  For  a  compiete  listing  and 
explanation  of  the  output  control  commands  avaiisfole  in  AURA,  the  analyst  is  referred  to  the 
AURA  Input  Manual  (Klopdc,  Sheroke.  and  Price  1990).  When  no  options  are  invoked,  only 
the  default  outputs  are  printed.  Default  outputs  consist  of  a  consoiidation  of  the  inputs  and  a 
report  of  the  final  average  results  at  each  reconstitution  time.  In  addition,  outputs  may  contain 
a  number  of  informative  warnings  or  error  messages  that  alert  the  analyst  to  inconsistencies 
or  errors  that  occur  within  the  input  runstream.  Familiarity  with  the  organization  of  the  output 
allows  the  analyst  to  locate  desired  results  efficiently  and  makes  for  easy  comparison  between 
the  various  tables  of  an  AURA  output.  The  following  outline  provides  the  general  sequence  of 
the  AURA  output  format. 

I.  CONSOLIDATION  OF  INPUTS 

A.  Mnemonic  Control  Cards 

B.  Heading 

C.  Event  Table  and  Miscellaneous 

D.  Weapons 

1 .  Names,  Yields,  Delivery  Errors 

2.  Dispersion  Pattern  Envelope  (TOXIC  Rounds) 

E.  Assets 

1 .  Names,  Numbers,  and  Other  Accounts 

2.  Degradation  Information 

3.  Reliability  and  Repair  Data 

F.  Link  Definition  Table 

G.  Link-Assets  Substitutability  Matrix 

H.  Subchains,  Oriinks,  Compound  Links,  and  Chains 
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I.  Chain  Plots 

J.  Deployment  Table 

K.  Deployment  Plots 

II.  INTERMEDIATE  RESULTS  FOR  EACH  REPLICATION  (Optional) 

A.  Weapon  Actual  Ground  Zero  Coordinates 

B.  Casualties,  Contaminations 

C.  Dosages  (Nuclear  or  Chemical) 

D.  Repairs  Commenced,  Ongoing,  and  Completed 

E.  Asset  Allocation:  Commander's  Decisions,  Available  Resources,  Weak 
Link  Reports 

F.  Replication  Summaries 

III.  FINAL  RESULTS  VS.  TIME 

A.  Unit  Effectiveness,  Statistics,  and  Distribution 

B.  Functional  Groups 

1 .  Survivors 

2.  Dosages 

3.  Contaminations 

C.  Link  Result  Table 

D.  CHAIN  Results 

IV.  REPEAT  OF  LETHALITY,  VULNERABILITY,  AND  DISSEMINATION  FILES 


2.2.1  Mnemonic  Control  Cards.  An  AURA  input  runstream  consists  of  many  sections, 
each  initiated  by  an  AURA  command  that  causes  some  action  to  be  taken.  The  commands 
separate  the  portions  of  an  input  runstream  and  are  referred  to  as  mnemonic  control  cards. 
As  the  input  runstream  is  processed,  an  output  table  is  printed  which  lists  the  mnemonics 
contained  in  the  runstream.  If  a  syntax  error  is  found  in  a  particular  section  of  the  runstream. 
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an  error  message  or  informative  warning  is  inciuded  in  the  output  tabie  foliowing  the  name  of 
the  mnemonic  being  processed.  The  printing  of  the  mnemonic  control  cards  provides  an  audit 
of  the  input  process.  That  is,  if  a  fatal  error  is  found  within  the  runstream,  the  user  can 
immediately  determine  which  mnemonic  problem  occurred.  Example  1  illustrates  a  mnemonic 
control  card  listing  in  which  no  errors  or  informative  warnings  have  occurred.  Example  2  is  an 
illustration  of  a  mnemonic  control  card  listing  with  error  messages  and  informative  warnings 
that  may  occur  during  pre-processing  of  input.  For  a  complete  discussion  of  the  mnemonics 
used  in  AURA,  the  analyst  is  referred  to  the  AURA  Input  Manual  (Klopcic,  Sheroke,  and  Price 
1990). 

2.2.2  Heading,  Event  Table,  and  Miscellaneous.  Example  3  illustrates  the  Heading,  Event 
Table,  and  miscellaneous  information  which  is  reported  near  the  beginning  of  the  output. 

Since  an  AURA  analysis  typically  consists  of  a  minimum  of  100  executions  of  the  code,  with 
each  run  (also  referred  to  as  a  trial)  being  a  slight  variation  from  every  other  run,  it  is 
important  to  clearly  identify  which  inputs  are  associated  with  each  set  of  outputs.  By 
accurately  identifying  each  run,  confusion  and  errors  which  may  otherwise  occur  in  the 
process  of  analyzing  the  results  can  be  eliminated.  The  purpose  of  this  initial  section  of  the 
input  consolidation  is  to  aid  the  analyst  in  identifying  the  unique  characteristics  of  the  run 
through  the  use  of  a  heading,  to  summarize  the  types  and  sequence  of  events  in  tabular 
format  for  easy  reference,  and  to  further  distinguish  it  by  the  values  assigned  to  some  of  the 
important  decision  rules  used  in  the  optimization  process. 

In  Example  3,  the  AURA  run  is  identified  by  the  following  heading:  "152-MM  SELF- 
PROPELLED  HOWITZER  BATTERY  WITH  BTRY  FDC  ONLY."  The  mnemonic  input  card 
HEADING  is  used  to  alter  the  heading  on  each  AURA  run  and  can  be  used  to  summarize  the 
important  variables  of  each  run.  The  run  is  further  identified  by  an  ID  number,  which  is  simply 
the  date  by  month/day/calendar  year  and  the  time  at  which  the  computer  run  was  executed. 

The  first  row  of  output  in  the  Event  Table  is  a  list  of  initial  set  of  random  number  seeds. 
Every  AURA  run  will  start  with  the  same  set  of  default  random  number  seeds  unless  otherwise 
specified  with  the  mnemonic  input  card  SEEDS.  In  fact,  verifying  that  the  initial  random 
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MNEMONIC  CONTROL  CARDS 
****************************** 


1.  AGENT 

2.  DEPLOYMENT 

4.  DELIVERY  ERROR 

5.  VOLLEY 

6.  LINKS  • 

7.  SUBCHAIN 

8.  ORUNK 

9.  COMPOUND  LINK 

10.  CHAIN 

11.  REPLICATION 

12.  INTERNAL  RECONSTITUTION 

13.  GO 


Example  1.  Mnemonic  Control  Cards  1. 
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Example  2.  Mnemonic  Control  Cards  2. 


152-MM  SELF  PROPELLED  HOWITZER  BATTERY  WITH  BTRY  FDC  ONLY 
RUN  ID#  11/14/90  8:47:20 

m*****#**********i****m**************************************************************************************************************** 
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number  of  seeds  remain  constant  over  a  set  of  runs  is  an  important  step  in  determining  the 
consistency  of  results  for  the  analysis  set. 

The  next  two  rows  of  the  table  are  column  headers  which  identify  the  information 
contained  in  the  Event  Table.  The  first  column  in  the  Event  Table  identifies  the  event  number. 
All  events  are  sequentially  numbered  in  the  order  in  which  they  are  processed.  The  second 
column  identifies  the  time  at  which  the  event  has  occurred.  In  Example  3,  event  1  occurs  at 
time  0.0.  Units  of  time  are  user  specified.  While  not  explicitly  defined,  ail  units  of  measure 
are  implied  by  the  input  values.  Care  should  be  taken  to  maintain  a  consistent  set  of  units. 
The  time  unit  of  choice  for  most  AURA  analyses  is  minutes.  Column  three  defines  the  type  of 
events  which  have  occurred.  AURA  event  types  are  described  in  detail  in  Section  5.b  of 
Volume  1  of  the  AURA  Programmer/Analyst  Guide  (Sheroke  et  al.  1990b).  As  shown  in  this 
example,  event  1  refers  to  the  initial  event  for  this  run.  For  all  AURA  runs,  the  initial  event  is 
a  reconstitution  event  occurring  at  time  0.0  in  which  AURA  initializes  all  assets  to  their 
maximum  effectiveness  level  and  primary  deployment  locations  before  commencing  the  run. 
Events  which  represent  the  detonation  of  a  threat  weapon  are  known  as  lethality  events. 
Lethality  event  types  include  TOXIC  DISPERSION.  CONVENTIONAL,  NUCLEAR,  and 
SECONDARY,  which  identify  chemical,  conventional,  or  nuclear  weapons  attacks,  or 
secondary  explosions,  respectively.  Other  AURA  event  types  include  the  following: 

•  User-defined  internal  reconstitution  events; 

•  Change  in:  delivery  errors, 

target  location  error, 
incoming  fire  direction, 
wind  direction, 
acquisition  probability. 

The  fourth  column  identifies  the  chain  or  mission  which  is  operant  at  the  corresponding 
time.  The  use  of  several  chains  over  different  time  intervals  may  be  implemented  through  the 
use  of  the  mnemonic  input  CHAINS.  Each  chain  will  be  identified  by  a  number  and  ordered  in 
the  sequence  in  which  the  chain  description  appears  in  the  input  runstream. 
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The  fifth  column,  which  is  headed  WPN  NO./RECUPTIME,  will  contain  either  the  weapon 
number  or  the  time  for  substitution  depending  upon  the  type  of  event  identified  for  the  row  of 
information.  In  Example  3.  an  infinite  (INF)  amount  of  recuperation  time  has  been  allowed  to 
pass  before  the  onset  of  the  scenario,  which  simply  means  that  at  the  start  of  the  scenario, 
the  unit  has  been  allowed  to  optimize  the  use  of  all  assets.  This  default  assumption  may  be 
altered  through  the  use  of  the  optional  TIME  BEFORE  ZERO  card  under  the  MODE 
mnemonic.  The  RECUPTIME  (or  recuperation  time)  identifies  a  time  after  an  event  at  which 
the  unit  commander  reconstitutes  unit  assets  by  substituting  personnel  and  equipment  assets 
into  the  most  mission-essential  tasks  in  order  to  maximize  unit  effectiveness.  The  values 
printed  for  RECUPTIME  in  this  column  are  the  values  input  under  the  mnemonic  input  card 
INTERNAL  RECONSTITUTION  TIME.  It  can  also  be  noted  from  the  data  in  this  column,  that 
only  one  weapon  type  was  employed  in  this  scenario  since  all  lethality  events  are  associated 
with  weapon  No.  1 .  Weapons  are  numbered  sequentially  in  the  order  in  which  the  are  read 
from  the  runstream.  Weapon  numbers  may  be  further  identified  through  use  of  the  Weapon 
Reliability  Table,  which  is  shown  in  the  following  section. 

Column  six  of  the  Event  Table  is  delineated  by  the  header  NO.RNDS  and  contains  the 
number  of  incoming  rounds  per  volley  for  lethality  events.  If  no  rounds  are  used  (i.e.,  only  a 
volley  is  specified),  this  entry  will  be  blank  in  the  table. 

The  remaining  columns  of  data  contain  the  inputs  associated  with  the  particulars  of  the 
lethality  events  which  were  described  in  the  input  runstream  via  the  ROUND  or  VOLLEY  input 
command.  Columns  eight  and  nine  identify  the  aim  point,  also  known  as  the  designated 
ground  zero  (DQZ)  of  ttie  volley.  AURA  uses  the  Cartesian  coordinate  system  where  the 
target  (military  unit)  is  typically  deployed  in  the  x-y  plane  using  meters  as  the  units  of 
measure.  Column  ten  lists  the  intended  height  of  burst  (HOB)  which  is  defined  along  tiie 
z-axis.  Column  eleven  identifies  the  angle  (VOLLEY  ANGLE)  at  which  the  rounds  are 
dispersed  with  respect  to  the  range  direction  (direction  of  incoming  fire),  and  column  twelve 
reports  the  distance  over  which  these  rounds  are  spaced,  in  this  example,  for  the  second 
event  (event  2),  16  conventional  rounds  were  fired  at  the  point  (255.00,  33.00),  and  the  height 
of  burst  was  defined  to  be  zero.  (Sheroke  et  al.  [1990b]  describes  the  usage  of  height  of 
burst  in  modeling  chemical,  conventional,  and  nuclear  attacks.)  These  rounds  will  be  evenly 
dispersed  across  a  distance  of  250  m  at  a  90°  angle  to  the  line  of  fire. 
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The  direction  of  the  tine  of  fire  is  given  under  MISCELLANEOUS  values  as  the  INCOMING 
FIRE  DIRECTION.  As  noted  in  Examfrie  3.  the  incoming  fire  direction  is  measured 
counterclockwise  from  the  target  x-axis.  Another  miscellaneous  value  which  may  be  an 
important  factor  especially  when  modeling  chemical  attacks  is  the  DOWN  WIND  DIRECTION. 
The  direction  of  the  wind  is  also  measured  counterclockwise  from  the  target  x-axis.  A  range 
of  angles  is  given  for  both  the  incoming  fire  and  downwind  directions  since  the  capability 
exists  to  randomly  sample  the  wind  or  fire  directions  over  a  specified  range  of  angles  using 
the  respective  mnemonic  input  cards,  iNCOMING  FIRE  DIRECTION  and  WIND  DIRECTION. 

In  this  example,  these  directions  were  input  as  constants,  both  0°.  It  is  important  to  note  and 
to  ensure  the  accuracy  of  the  relationships  between  each  of  the  different  coordinate  systems 
used  in  an  AURA  run.  The  line  printer  plot  of  the  deployment  is  useful  for  verification  of  these 
coordinate  systems,  see  Sections  2.2.14  and  2.2.15. 

Stepping  back  to  the  top  of  the  MISCELLANEOUS  values,  the  first  value  identified  is  the 
number  of  replications  of  the  encounter  performed  for  the  particular  run.  This  value  should 
remain  constant  throughout  the  production  phase  of  an  analysis;  however,  it  is  wise  to  test 
several  values  to  ensure  the  stability  of  casualty  and  unit  effectiveness  results.  Typically 
100  replications  is  sufficient  to  ensure  good  resuits.  AURA  encounters  which  consider  a  large 
number  of  random  variables  may  require  as  many  as  200  replications,  which  is  still  not 
prohibitively  large. 

The  next  line  of  data  printed  under  the  MISCELLANEOUS  values  is  the  user  input  values 
for  INTERNAL  RECONSTITUTION  times.  These  are  the  times  following  each  EVENT  at 
which  the  commander  will  reorganize  and  reallocate  unit  assets  in  order  to  maximize  unit 
effectiveness  for  the  mission  modeled. 

The  next  three  lines  of  comment  under  the  MISCELLANEOUS  values  refer  to  decision  rule 
values.  The  use  of  various  options  under  the  mnemonic  input  card  DECISION  RULES  allows 
for  control  of  certain  sets  of  decision  logic  employed  by  the  optimization  algorithm  in  choosing 
assignments  into  the  various  unit  tasks  (LINKS).  The  first  of  these  decision  rule  values 
pertains  to  the  rules  governing  the  substitution  of  assets  into  LINKS.  In  the  default  case, 
substitutions  are  chosen  on  the  basis  of  versatility.  In  AURA,  the  asset's  versatility  represents 
how  well  the  asset  is  cross-trained  to  perform  the  tasks  within  the  unit.  AURA  will  initially 
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attempt  to  substitute  assets  based  upon  their  versatility,  with  the  least  versatile  assets  being 
substituted  first.  The  fractional  improvement  needed  to  override  this  default  decision  rule  is 
defined  by  the  optional  input  card  PRIORITY.  In  this  example,  the  fractional  improvement  in 
link  effectiveness  required  in  order  to  preempt  the  default  decision  rule  in  favor  of  substitution 
on  the  basis  of  user-ordered  priority  is  0.01  (or  1%). 

The  next  line  of  output  provides  the  value  associated  with  criterion  used  to  replace 
fatigued  or  sick  personnel.  The  default  value  for  substittition  is  set  at  0.75.  That  is,  if 
personnel  who  are  performing  the  primary  duties  assigned  to  them  (HOME  LINK)  become 
fatigued  from  lack  of  rest  or  sickness  due  to  sublethai  dosages  of  chemical  agent  or  radiation 
such  that  their  performance  drops  below  75%  of  the  capability,  the  commander  (the  asset 
allocation  algorithm)  will  search  for  and  replace  these  assets  with  other  personnel  who  can 
substitute  into  the  task  at  a  higher  effectiveness  value  and  thereby  increase  overall  unit 
effectiveness.  The  default  level  of  degradation  required  for  substitutions  to  take  place  may  be 
varied  using  the  option  SICKLV  under  the  mnemonic  card  DECISION  RULES. 

In  Example  3,  the  relative  importance  of  finishing  ongoing  repairs  is  set  to  2.0.  This 
means  that  if  an  ongoing  repair  has  0.6  of  an  item  left  to  fix,  the  code  will  calculate  the 
anticipated  gain  based  upon  receiving  1 .2  (=  2.0  *  0.6)  items.  The  value  of  this  variable  is  set 
using  the  FINISH  REPAIR  option  under  the  mnemonic  input  card  DECISION  RULES.  This 
allows  the  optimization  algorithm  to  optimize  unit  performance  by  selecting  for  repair  the  items 
of  equipment  which  most  contribute  to  the  effectiveness  of  the  mission. 

2.2.3  Weapon  Reliability  Table.  The  Weapon  Reli^ility  Table  reports  a  consolidation  of 
the  weapon  information  specified  in  the  input  runstream.  For  each  weapon,  parameters  are 
defined  describing  the  delivery  errors  and  weapon  reliett)ility  data.  A  typical  Weapon  Reliability 
Table  is  illustrated  in  Example  4. 

The  first  column  lists  the  weapon  number.  Wessons  are  numbered  with  respect  to  the 
order  in  which  they  appear  in  the  input  runstream.  The  next  entry  in  the  table  is  the  weapon 
type.  Weapon  type  can  be  conventional,  nuclear,  chemical,  or  conventional-chemical  and  is 
referenced  by  the  numbers  1,2,3,  and  4,  respectively. 
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Example  4.  Weapon  Reliability  Table. 


The  next  column  of  the  Weapon  Reliability  Table  reports  either  the  nuclear  blast  yield 
(YLD  [BLST])  or  lethal  type  (LTHTYP)  for  conventional  and  chemical  runs.  When  playing  a 
nuclear  scenario,  the  yield  (blast)  refers  to  the  size  of  the  nuclear  weapon.  For  example,  if  a 
5-kt  bomb  is  specified  in  the  input  runstream,  then  5.00  KT  would  appear  in  this  column. 

When  the  scenario  being  modeled  is  chemical  or  conventional,  the  lethal  type  for  the  weapon 
deployed  will  be  listed  in  this  column.  Possible  lethal  types  for  chemical  include  G,  V,  and  H 
for  nonpersistent,  persistent,  and  blistering  agents,  respectively.  For  a  conventional  weapon, 
the  lethal  type  will  always  be  represented  by  a  *1 ." 

The  fourth  column  contains  either  the  nuclear  radiation  yield  (YLD  [RAD])  or  the  maximum 
effective  radius  for  conventional  and  chemical  runs.  The  radiation  yield  will  be  the  same  as 
the  blast  yield  unless  a  second  yield  is  specified  in  the  YiELD  section  of  the  input  runstream. 
The  second  yield  is  optional  and  allows  the  user  to  model  enhanced  radiation  effects.  When 
this  option  is  used,  the  value  specified  in  the  inputs  will  appear  in  this  column  of  the  table. 

For  further  information  on  the  YIELD  command,  the  user  is  referred  to  Volume  1  of  the  AURA 
Programmer/ Analyst  Guide  and  the  AURA  Input  Manual  (Sheroke  et  al.  1990b;  Klopcic, 
Sheroke,  and  Price  1990).  For  conventional  and  chemical  scenarios,  column  four  contains  the 
maximum  effective  radius  for  the  given  weapon.  The  maximum  effective  radius  is  simply  the 
radius  from  the  actual  ground  zero  in  which  the  weapon  effects  occur.  In  other  words,  no 
weapon  effects  are  taken  into  consideration  beyond  this  radius. 

The  next  portion  of  the  Weapon  Reiiabiiity  Table  contains  the  delivery  errors  defined  for 
each  w^pon.  Delivery  error  values  greater  than  zero  indicate  that  the  error  is  sampled  from 
a  normal  distribution  while  values  less  than  zero  indicate  that  the  error  is  sampled  from  a 
uniform  distribution.  A  message  stating  this  relationship  is  included  following  the  tabulated 
weapon  information.  Round-to-round  and  volley  refer  to  the  error  in  round  and  volley  delivery, 
respectively.  Round-to-round  and  volley  errors  are  given  for  both  the  range  and  deflection. 
Range  refers  to  the  distance  between  the  gun  and  the  target,  whereas  deflection  refers  to  the 
number  of  meters  to  the  right  or  left  of  the  aim  point  with  respect  to  the  firing  direction.  When 
sampling  from  a  normal  distribution,  the  values  given  in  the  table  are  standard  deviations  from 
the  designated  ground  zero  in  both  range  and  deflection  for  the  round  and  volley.  When 
sampling  from  a  uniform  distribution,  these  values  relate  to  the  maximum  distance  from  the 
aim  point,  in  range  and  deflection,  that  the  round  may  fall.  For  more  detail  on  delivery  errors. 
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the  user  is  referred  to  the  DELIVERY  ERROR  sections  of  Volume  1  and  the  AURA 
Programmer/Analyst  Guide  and  the  AURA  Input  ManusJ  (Sheroke  et  al.  1990b:  Kiopcic, 
Sheroke,  and  Price  1 990). 

The  next  entry  in  the  table  is  the  height  of  burst  (HOB),  which  is  simply  the  "z"  coordinate 
or  the  distance  above  the  ground  at  which  the  weapon  detonates.  Following  the  HOB  is  Vne 
round  and  volley  reliability  data  for  each  weapon.  The  default  value  for  both  the  round  and 
volley  is  1 .00,  which  means  that  each  round  and  volley  has  a  probability  of  detonation  of 
1 00%.  This  value  will  always  appear  in  the  table  unless  otherwise  specified  in  the  input 
runstream.  The  last  column  of  the  table  reports  the  names  for  the  weapon  listed.  This 
column  contains  the  primary  name,  followed  by  any  ^temative  or  secondary  names  defined 
for  each  weapon. 

Finally,  under  the  tabulated  data  described  above,  is  a  line  of  additional  information 
concerning  the  weapon(s)  deployed.  The  first  item  reported  is  the  initial  target  location  error 
(TLE).  TLE  values  are  standard  deviations  that  represent  the  distance  from  the  aim  point 
within  which  the  target  is  expected  to  lie  approximately  one-third  of  the  time.  Similar  to  the 
delivery  error  is  the  relation  between  the  sign  of  the  values  given  for  the  TLE  and  the 
distribution  that  is  modeled  (i.e.,  values  greater  than  zero  indicate  sampling  from  a  normal 
distribution,  while  values  less  than  zero  indicate  sampling  from  a  uniform  distribution).  The 
type  of  distribution  that  is  being  used  is  listed  following  the  information  for  the  TLE.  For  a 
complete  discussion  of  target  location  errors,  the  user  is  referred  to  Volume  1  of  the  AURA 
Programmer/Analyst  Guide  (Sheroke  et  al.  1990b).  Next,  the  initial  acquisition  probability  is 
given.  This  value  indicates  the  probability  of  acquiring  the  target.  When  no  data  is  given  for 
this  input,  the  AURA  code  assumes  a  value  of  1.00  or  100%  probability  of  target  acquisition. 

2.2.4  Toxic  Dissemination  Summary.  Example  5.  the  Toxic  Dissemination  Summary 
Table,  details  the  characteristics  inherent  to  the  employment  of  chemical  weapons  such  as  the 
following:  contamination  times,  agent  type,  dissemination  pattern,  and  levels  of  concentration. 
The  values  reported  in  the  summary  are  calculated  by  the  Non-Uniform  Simple  Surface 
Evaporation  (NUSSE)  model,  which  is  the  chemical  dissemination  and  transport  methodology 
used  by  AURA.  Developed  by  the  U.S.  Army  Chemical  Research,  Development,  and 
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TOXIC  DISSEMINATION  SUMMARY 
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Example  5.  Toxic  Dissemination  Summary  Table. 


Engineering  Command  (CRDEC),  the  methodology  encompassing  NUSSE  and  its  applicability 
within  AURA  is  detailed  in  Sheroke  (1990b).  It  should  be  noted  that  NUSSE  Output  is 
prepared  for  input  to  AURA  by  the  preprocessor,  PRETOX  (Hindman  1990).  The  complete 
listing  of  information  provided  by  PRETOX  may  be  appended  to  the  AURA  standard  output  file 
by  use  of  the  LETHALITY  ou^jut  option. 

The  Toxic  Dissemination  Summary  Table  is  of  primary  use  as  a  reference  source  when 
modeling  chemical  environments.  The  following  information  provides  the  analyst  with  the 
necessary  knowledge  to  best  utilize  and  understand  the  information  provided  by  the  Toxic 
Dissemination  Summary. 

The  first  section  of  the  table  reports  the  minimum  contamination  level  and  corresponding 
dissemination  pattern  to  be  considered  for  the  modeling  scenario.  The  contamination  value  is 
input  into  NUSSE  as  the  minimum  deposition  level  of  the  chemical  agent.  The  contamination 
value  is  specified  in  milligrams  per  square  meter  (mg/m^).  The  corresponding  chemical  cloud 
pattern  characteristics  are  also  reported  in  this  section  and  include  the  cloud  arrival  and 
evaporation  times,  the  cloud  pattern  dimensions  (in  terms  of  downwind  and  crosswind 
coordinates),  and  the  persistence  time  (PRSTIM)  of  the  chemical  pattern.  In  Example  5,  the 
minimum  deposition  level  considered  is  1.0  mg/m^  the  arrival  time  is  0.21  min,  and  the 
evaporation  time  is  90.0  min.  The  length  of  the  cloud  pattern  is  described  by  the  coordinates 
given  in  the  downwind  direction.  In  this  example,  the  length  of  the  pattern  is  from  70  m  to 
1 ,000  m  on  the  modeling  grid.  Likewise,  the  width  of  the  pattern  is  described  in  terms  of  the 
crosswind  coordinates.  The  width  of  this  pattern  in  this  example  ranges  from  -90  m  to  90  m. 
The  last  datum  provided  in  this  section  describes  the  persistence  time  (PRSTIM)  of  the 
chemical  cloud.  Defined  in  terms  of  minutes,  the  persistence  time  reflects  the  total  amount  of 
time  (evaporation  time  plus  additional  time  required  for  the  cloud  to  ’drift’  away)  the  chemical 
will  remain  in  effect  during  which  the  contamination  level  exceeds  the  minimum  contamination 
considered. 

The  next  section  of  the  Toxic  Dissemination  Summary  Table  briefly  describes  the  chemical 
dosage  to  be  considered  for  the  modeling  scenario.  The  chemical  dosage  section  first  reports 
the  times  of  interest  or  sampling  times  (in  minutes)  to  be  considered  for  the  scenario.  The 
remainder  of  this  section  describes  the  dosage  characteristics  of  the  chemical  agent(s) 
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employed.  For  each  type  of  hazard  (vapor  or  percutaneous),  the  information  reported  is  the 
minimum  dosage  level  and  the  length/width  of  the  cloud  pattern.  Also  reported  for  each 
chemical  hazard  are  the  concentration  level  and  pattern  coordinates.  These  values  are 
normalized  with  respect  to  the  minimum  level  of  contamination  considered  by  AURA.  In 
Example  5,  the  information  describes  a  vapor  hazard  which  will  be  evaluated  to  a  minimum 
dosage  level  of  at  least  (134.0  mg-min.)/(m^).  The  length  of  the  cloud  pattern  associated  with 
this  vapor  agent  ranges  from  120.07  m  to  577.18  m.  The  width  of  this  agent’s  doud  pattern 
ranges  from  -22.98  m  to  22.98  m.  Similar  information  is  reported  for  the  maximum  dosage 
level  of  the  vapor  agent  and  both  the  minimum  and  maximum  dosage  levels  of  the 
percutaneous  agent.  The  analyst  is  reminded  that  this  table  is  a  brief  description  of  the 
chemical  cloud  pattern.  A  complete  description  may  be  obtained  through  use  of  the  output 
option,  LETHAL.  (See  Input  Manual.) 

The  next  section  reported  in  the  Toxic  Dissemination  Summary  Table  describes  the  value, 
location,  and  time  of  the  peak  concentration  level  realized  during  the  given  scenario.  In  this 
example,  the  peak  concentration  level  attained  in  the  pattern  was  32.7  mg/m®  at  pattern 
coordinate  (240.,  0.)  at  .80  min  after  munition  detonation. 

Finally,  the  time  required  for  the  cloud  to  drift  past  the  unit  is  reported.  Based  on  unit  size 
and  wind  speed,  this  time  is  simply  the  difference  between  the  persistence  time  and 
evaporation  time  of  the  chemical  cloud. 

2.2.5  Asset  Table.  The  Asset  Table  reports  the  status  of  all  assets  deployed  in  the  unit. 
The  table  is  separated  into  two  parts  with  the  first  containing  a  list  of  personnel  and  the 
second  containing  a  list  of  equipment.  The  personnel  assets  section  can  be  output  in  two 
fashions.  When  playing  sleep  deprivation  (using  the  FATIGUE  mnemonic),  AURA  reports 
each  asset's  sleep  deprivation  status  in  conjunction  with  the  information  provided  in  the  asset 
status  table.  If  sleep  deprivation  is  not  being  played,  the  Asset  Status  Table  reports  the 
names  and  associated  data  for  all  assets  listed  in  the  input  runstream.  Example  6  illustrates  a 
typical  Asset  Table.  Example  7  illustrates  the  personnel  section  of  an  Asset  Table  where 
sleep  deprivation  was  modeled.  Each  format  of  the  Asset  Status  Table  is  described  in  the 
following  paragraphs. 
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ASSE1S 

******* 


EERSOMMEL 


ID 

VRS 

NO. 

EflPLOYD 

NAMES 

1 

2 

1.0 

FIREMEN.  PERSONNEL 

2 

2 

20.0 

FIRETEAM,  PERSONNEL 

16 

3 

20 

USERS  A.  PERSONNEL.  USER 

17 

3 

20 

USERS  B.  PERSONNEL.  USER 

18 

3 

20 

USERS  C.  HBRSCMWEL.  USER 

19 

3 

20 

USERS  D.  reRSCHWEL.  USER 

20 

3 

20 

USERS  E.  reRSONNEL.  USER 

EQUIPMENT 


SPECIAL  ASSOC 


ID 

VRS 

IVL  CNTBU 

PRSPC-MX/MN 

FACET  VALUE  NO. 

NAMES 

3 

1 

-1  1 

1.00/1.00 

4.00 

RECORDS 

4 

1 

-1 

l.OC/1.00 

6.00 

CRANES 

5  2  -1 

1.0(yi.00 

1.00 

FRKLFT6A.  FORKLIFT6.  FORKLIFT 

6  2-1 

i.o(yi.oo 

1.00 

FRKLFT6B.  FORKL1FT6.  FORKLIFT 

WHERE; 


ID 

internally  assigned  asset  number 

VRS 

versatility,  jobs  this  asset  can  do 

IVL 

=  0  -  PerscHinel 
<  1  -  No  data  specified 
>  1  ~  Nuc  Vuln  Cbde  # 

CNTBU 

chains  in  which  this  item  can  be  used  in  a  contaminated  state 

PRSFC 

maximum  and  minimum  persistence  factors  (pertain  to 
chemical  contamination 

SPECIAL  FACET 

ASSOC  VALUE 

NO.  DPLOYD 

indicates  special  characteristic  of  asset 
possible  entries  are:  "XPND  BY  RPR"  and  "2NDRY  EXPL" 
value  associated  with  special  facet  characteristic  -  ie. 
expenditure  rate  for  XPD  BY  RPR  special  facet, 
number  of  items  deployed 

Example  6.  Assets  Table  -  Basic. 
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The  asset  identification  number  (iD),  versatility  (VRS),  number  of  assets  deployed  (NO. 
DPLOYD),  and  NAMES  are  entries  common  to  both  the  personnel  and  equipment  portions  of 
the  Asset  Table.  The  first  column  lists  the  identification  number  of  each  asset.  This  number 
is  internally  assigned  by  the  AURA  code  and  is  unique  to  each  asset.  The  next  column 
contains  the  asset’s  versatility  value.  Versatility  refers  to  the  total  number  of  jobs  that  an 
asset  can  perform  within  the  mission  modeled.  For  example,  a  record  clerk  may  have  a 
versatility  number  of  three.  This  means  that  the  record  clerk  is  able  to  perform  the  job  of  a 
record  clerk  and  has  the  ability  to  substitute  into  two  otfier  jobs  if  necessary.  Versatility  may 
be  viewed  as  the  depth  of  cross-training  an  asset  possesses.  The  next  to  the  last  entry  in 
each  section  of  the  Asset  Table  is  the  number  of  assets  deployed.  The  number  deployed  is 
the  total  number  of  assets  comprising  that  particular  asset  group.  The  right-most  column  of 
the  Asset  Table  contains  the  unique  asset  name  followed  by  any  alternate  names  specified  for 
that  asset  in  the  input  runstream.  Alternate  names  are  used  to  associate  common  parameters 
to  groups  of  assets.  The  user  is  referred  to  the  AURA  input  manual  for  more  information  on 
the  NAMES  mnemonic  (Klopcic,  Sheroke,  and  Price  1990). 

Entries  contained  solely  in  the  equipment  portion  of  the  asset  table  include  the  nuclear 
vulnerability  code  (IVLARY  or  IVL),  the  contaminated  but  usable  assets,  maximum  and 
minimum  chemical  agent  persistence  factors,  special  facet,  and  associated  value.  IVL  is  a 
multi-purpose  variable  that  enables  AURA  to  both  distinguish  whether  an  asset  is  personnel  or 
equipment  or  when  modeling  a  nuclear  scenario,  report  the  nuclear  vulnerability  code  for 
equipment  assets.  An  IVL  value  of  "0"  indicates  a  personnel  asset,  and  a  nonzero  IVL  value 
indicates  equipment.  Since  AURA  separates  personnel  and  equipment  prior  to  reporting  this 
table,  the  IVL  value  is  not  reported  in  the  personnel  section.  For  equipment  assets,  an  IVL 
value  of  "-1 "  indicates  that  there  is  no  nuclear  vulnerability  data  entered  for  the  equipment, 
whereas  an  IVL  value  greater  than  zero  corresponds  to  the  nuclear  vulnerability  code 
assigned  to  the  equipment  which  AURA  uses  to  translate  how  to  model  the  nuclear  effects  on 
that  equipment  asset. 

The  next  entry  under  the  equipment  section  of  the  Asset  Table  is  the  contaminated  but 
usable  assets.  This  entry  lists  the  number  of  the  chain  in  which  this  item  can  be  used  if 
contaminated.  In  a  chemical  scenario,  the  minimum  and  maximum  persistence  factors  for  the 
chemical  agent  are  reported. 
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The  next  entries  are  the  special  facet  and  associated  value.  Special  facet  refers  to  some 
characteristic  of  the  listed  asset  that  is  not  common  to  every  asset.  For  example,  a  special 
facet  may  be  "expendable  by  repair"  or  "secondary  explosive  source."  Some  special  facets 
have  an  associated  value  which  further  describe  ttte  special  facet.  If  "expendable  by  repair"  is 
listed  as  a  special  facet,  then  an  expenditure  rate  for  that  asset  will  be  reported  under  the 
associated  value.  An  example  of  a  special  facet  with  no  associated  value  would  be  a 
"secondary  explosive  source"  in  which  the  associated  value  entry  would  typically  remain 
blank. 

When  modeling  FATIGUE,  the  personnel  portion  of  the  Asset  Table  includes  seven 
additional  data  values  relating  to  the  fatigue/sleep  deprivation  status  of  each  asset.  These 
values  are  output  between  the  "VRS"  column  and  the  "NO.  DEPLOYD"  column  headers  of  the 
standard  Asset  Table.  The  first  of  these  columns,  "NO.  REST,"  contains  the  maximum 
amount  of  SLUNITs  allowable  for  each  asset.  Recall,  a  SLUNIT  (Sleep  UNIT)  is  a  unit  of 
measure  used  to  represent  the  amount  of  rest  associated  with  a  personnel  asset  (1  SLUNIT  3 
1  min  of  fully  efficient  rest).  In  other  words,  once  an  asset  accumulates  a  particular  amount  of 
SLUNITs,  the  asset  will  not  be  allowed  to  rest  until  some  SLUNITs  are  used  (SLUNITS  are 
expended  by  working).  The  second  column,  headed  by  "MUST  REST,"  reports  the  minimum 
amount  of  SLUNITs  allowable  for  each  asset.  In  other  words,  once  an  asset  falls  below  this 
level  of  stored  SLUNITs.  the  asset  will  be  forced  to  rest.  The  third  column  is  headed  by 
"REST  DURATION"  and  contains  the  value  of  duration  of  rest  for  each  asset.  The  rest 
duration  value  is  the  amount  of  time  that  an  asset  must  be  allowed  to  rest  once  assigned  to 
sleeping  quarters.  The  fourth  column  reports  the  amounts  of  SLUNITS  that  each  asset 
possesses  at  the  start  of  each  replication.  The  fifth  column  reports  the  fatigue  rate  multiplier 
(FAT  MULT)  assigned  to  each  asset.  The  fatigue  rate  multiplier  is  an  optional  user-defined 
parameter  which  allows  the  user  to  give  a  distribution  of  fatigue  rates  for  all  assets  in  a  job. 
This  allows  the  modeling  of  the  variances  in  fatigue  rates  for  each  person  within  the  link  or 
job.  The  threshold  multiplier  reported  in  the  next  column  enables  the  assignment  of  threshold 
values  for  the  upper  and  lower  limits  of  asset  fatigue  rates.  The  threshold  values  can  be  used 
in  conjunction  with  the  fatigue  rate  multiplier  to  describe  an  asset's  resiliency  toward 
fatigue/sleep  deprivation.  For  example,  a  weak  asset  would  have  both  a  high  fatigue  rate 
multiplier  and  high  threshold  multiplier  values,  while  a  strong  asset  would  have  low  fatigue 
rate  and  threshold  multiplier  values.  The  final  data  value  reported  when  playing  fatigue  is  the 
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maximum  uptime  (MAX  UPTIME)  parameter.  This  value,  like  the  fatigue  multipliers,  is  an 
optionally  assigned  parameter.  The  maximum  uptime  parameter  refers  to  the  maximum 
amount  of  time  (in  minutes)  an  asset  is  permitted  to  function  without  sleep.  The  maximum 
uptime  parameter  allows  the  user  to  define  the  maximum  amount  of  time  that  an  asset  is 
capable  of  working  without  sleep. 

2.2.6  Nuclear  Posture  and  Shielding  Table.  The  Nuclear  Posture  and  Shielding  Table, 
shown  in  Example  8.  reports  the  nuclear  neutron-to-gamma  dosage  ratios  associated  with 
each  nuclear  posture  as  declared  via  the  SHIELDING  command.  The  first  column  of  the 
Nuclear  Posture  and  Shielding  Table  simply  reports  the  nuclear  posture  as  defined  by  the 
SHIELDING  command.  Columns  2-5  represent  the  nudear  shielding  factors,  defined  as 
neutron-to-gamma  ratios  for  each  nuclear  posture.  The  nuclear  shielding  factors  are  defined 
as  the  ratio  of  nuclear  neutron  dosages  with  respect  to  the  fraction  of  the  incidental  gamma 
dosage.  In  AURA,  the  nudear  shielding  factors  are  described  by  each  of  the  following  ratios: 

(N,  N)  -  Neutron-to-neutron; 

(N,  G)  -  Neutron-to-gamma; 

(G,  N)  -  Gamma-to-neutron; 

(G,  G)  -  Gamma-to-gamma; 

The  ratio  (A,  B)  reported  is  the  fraction  of  dosage  of  Type  B  due  to  an  incident  dosage  of 
Type  A.  For  example,  in  the  second  ratio  described  above,  the  resultant  ratio  would  be  the 
fraction  of  gamma  dosage  (G)  due  to  the  incident  neutron  dosage  (N).  This  is  expressed  as 
(N,  G)  and  represents  the  neutron-to-gamma  ratio  for  the  posture.  Associated  with  each 
posture  is  a  full  matrix  of  shielding  factors— namely.  (N.  N),  (N.  G),  (G,  N),  and  (G,  G). 
Column  six  of  the  Nudear  Posture  and  Shielding  Table  contains  the  description  of  the 
assodated  nudear  posture  number.  In  AURA,  the  nudear  postures  are  defined  as  follows: 
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Examples.  Nuclear  Posture  and  Transmission  Table. 


1  in  the  open 

2  In  the  open  but  thennally  shielded 

3  in  a  foxhole 

4  In  an  armored  personnel  carrier 

5  In  a  tank 

The  Nuclear  Posture  and  Shielding  Table  next  reports  the  two  meteorological  conditions 
which  AURA  considers  in  the  nuclear  environment:  atmospheric  quality  and  MOPP  uniform 
type.  The  atmospheric  quality  is  specified  in  general  terminology  and  may  be  defined  in  the 
THERMAL  input  command  as  GOOD,  AVERAGE,  or  POOR.  The  default  atmospheric  quality 
in  AURA  is  AVERAGE.  The  uniform  type  is  also  described  In  the  THERMAL  command  and  is 
defined  as  SUMMER  or  WINTER.  The  default  uniform  type  is  SUMMER.  AURA’S  nuclear 
vulnerability  methodology  (described  in  Volume  1)  details  the  impact  of  these  meteorological 
conditions  to  unit  personnel. 

Finally,  if  the  associated  asset  name  option  is  specified  within  the  SHIELDING  command, 
the  Nuclear  Posture  and  Shielding  Table  prints  the  name  of  the  associated  asset  in  the  last 
column.  To  explain  further,  usage  of  the  associated  asset  name  option  affords  the  personnel 
assets  in  a  vehicle  the  same  nuclear  blast  criterion  as  the  associated  vehicle.  Therefore,  the 
personnel  assets  in  a  vehicle  will  be  considered  casualties  when  the  vehicle  becomes  a 
casualty. 

2.2.7  Toxic  Penetration  Factors  Table.  The  Toxic  Penetration  Factors  Table  reports  the 
degradation  inherent  to  personnel  in  a  chemical  environment.  The  two  items  reported  in  this 
table  are  the  degradation  resulting  from  wearing  mission-oriented  protection  posture  (MOPP) 
gear  and  the  dosage  multiplier,  which  is  input  under  the  Toxic  Kill  Criteria  (T.K.C.)  card  and 
defined  for  each  asset  group.  Example  9  illustrates  the  Toxic  Penetration  Factors  Table.  The 
toxic  penetration  factors  table  is  a  default  output  produced  by  AURA.  That  is,  the  table  will  be 
printed  regardless  of  scenario  modeled.  If  a  chemical  scenario  is  not  modeled,  the  toxic 
Penetration  Factors  Table  will  contain  the  default  values  assigned  for  MOPP  and  T.K.C.  and 
will  have  no  impact  on  the  nonchemical  scenario.  The  MOPP  values  reported  in  the 
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Example  9.  Toxic  Penetration  Factors  Table. 


nonchemicaf  scenario  may  be  useful  to  present  the  case  when  personnel  are  required  to  don 
MOPP  gear  upon  the  arrival  of  every  incoming  round  until  an  all  clear  (i.e.,  false  alarm  signal) 
has  been  given. 

The  first  column,  the  T.K.C.  Code,  lists  the  toxic  kill  criteria  code  numbers  and  descriptions 
that  have  been  defined  in  the  input  runstream  under  the  mnemonic  T.K.C.  The  next  column 
lists  the  dosage  multiplier  (also  defined  under  the  mnemonic  T.K.C.).  The  dosage  multiplier  is 
used  to  simulate  higher/lower  than  normal  dosage  ratios,  as  would  be  acquired  by  a  person 
whose  task  required  a  higher/lower  than  normal  breathing  rate.  The  subsequent  five  columns, 

headed  by  MOPPO,  MOPP1 . MOPP4,  report  the  effective  fractional  capability  of  an  asset 

to  perform  its  assigned  task  while  in  MOPP.  For  example,  in  the  column  headed  by  MOPPO, 
which  means  no  MOPP  gear  is  worn,  the  personnel  in  all  categories  can  operate  at  100%. 

The  degradation  due  to  MOPP  is  in  direct  proportion  to  the  level  of  MOPP  gear  being  worn. 
The  degradation  values  for  the  various  MOPP  postures  may  be  defined  under  the 
DEGRADATION  mnemonic.  If  the  MOPP  values  are  not  defined  in  the  input  runstream,  the 
MOPP  table  reports  the  AURA  defaults  for  MOPP  for  the  first  asset  listed  in  the  table.  While 
all  values  are  printed  in  the  table,  AURA  has  the  capability  to  model  only  two  postures,  the 
original  posture  and  the  alternate  posture,  as  specified  in  the  input  runstream.  In  Example  9, 
the  original  and  alternate  postures  are  MOPP2  and  MOPP4,  respectively.  The  printing  of 
default  values  under  MOPPO,  MOPP1,  and  MOPP4  does  not  affect  results.  In  Example  9, 
entries  under  MOPP2  and  MOPP4  are  user-specified  inputs.  Values  listed  under  MOPPO, 
MOPP1 ,  and  MOPP4  are  defaults.  The  dashes  listed  under  MOPP1  and  MOPP3  indicate  that 
there  are  no  data  for  tnese  entries.  Generally,  only  four  levels  of  MOPP  are  modeled  under 
the  current  doctrine:  however,  AURA  provides  the  capability  to  define  alternative  MOPPs  if 
necessary.  MOPPS  and  above  may  be  defined  as  needed  to  model  special  poshjres  which 
may  be  required  within  the  infinite  spectrum  of  modeling  possibilities.  It  should  be  noted  that 
although  the  term  MOPP  is  used,  this  terminology  also  applies  to  the  modeling  of  chemical 
protective  postures  of  red  units.  For  these  special  postures,  the  user  must  define  the  values 
for  the  various  T.K.C.  codes  as  well  as  the  MOPP  degradation  values.  For  more  information 
on  T.K.C.  and  MOPP  degradation  values,  the  user  Is  referred  to  the  AURA  Input  Manual 
(Klopcic,  Sheroke,  and  Price  1990). 
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Following  the  T.K.C.  and  MOPP  degradation  information  are  the  toxic  penetration  factors 
for  vapor  (agents  that  affect  personnel  through  inhalation)  and  percutaneous  (agents  that  are 
absorbed  through  the  skin)  hazards.  Vapor  and  percutaneous  dosages  are  reported  in 
Example  9  as  a  fraction  of  the  total  possible  dose  that  can  be  received  for  each  of  the  various 
MOPP  levels.  As  the  MOPP  posture  increases,  or  more  protective  clothing  is  donned,  the 
fraction  received  by  inhalation  or  absorption  decreases.  For  instance,  in  Example  9,  under 
MOPPO  (no  protective  clothing  worn),  the  percentage  of  the  total  dose  received  is  1 .00  or 
100%.  Under  MOPP1  (overgarment  only),  the  value  for  vapor  hazard  remains  at  100%  while 
the  value  for  percutaneous  hazard  has  dropped  to  0.20  (or  20%).  The  values  for  the 
penetration  factors  may  be  specified  under  the  mnemonic  MOPP.  When  no  specifications  are 
given,  the  default  values  are  reported  for  the  various  MOPP  postures.  As  in  the  case  of  the 
degradation  by  MOPP,  values  for  the  penetration  factors  may  be  specified  for  MOPP  postures 
of  five  and  above  when  deemed  necessary.  Further  information  on  penetration  factors  may 
be  found  in  the  AURA  Input  Manual  (Klopcic,  Sheroke.  and  Price  1990). 

2.2.8  Repairable  Item  Data  Table.  The  Repairable  Item  Data  Table  prints  the  input  data 
related  to  the  repair  of  damaged  or  failed  equipment.  Repairs  can  be  specified  at  three  levels: 
0  decontamination  needed  (chemical  only),  1  s  light  repair  needed,  and  2  =  medium  repair 
needed.  For  each  repairable  asset  group,  the  Repairable  Item  Data  Table  contains  a  iine  of 
data  for  each  type  of  repair  that  has  been  specified.  For  exampie,  if  iight  and  medium  repairs 
have  been  specified  for  an  asset  group,  then  a  line  of  data  for  light  and  a  line  of  data  for 
medium  repair  will  be  printed  in  the  table.  If  decontamination  is  needed  in  addition  to  light 
and  medium  repair,  then  a  third  line  pertaining  to  decontamination  wiil  be  printed  for  that  asset 
group,  in  Example  10,  both  light  and  medium  repairs  have  been  specified  for  all  repairable 
assets;  therefore,  two  lines  of  data  are  included  in  the  table  for  each  asset. 

The  first  column  of  the  Repairable  Item  Data  table  lists  the  identification  number  and  name 
for  each  repairable  asset  group.  The  next  column  reports  the  damage  levels  (or  repair  leveis) 
that  have  been  specified  for  each  asset.  Light  damage  may  be  thought  of  as  any  damage 
that  will  take  one  hour  or  less  to  repair  and  medium  damage  as  damage  that  wiil  take  from  1 
to  8  hr  to  repair.  Alternately,  light  damage  may  be  thought  of  as  damage  repairadDle  by  the 
crew  and  medium  damage  as  damage  repairable  by  organizational  level  assets.  Heavy 
damage  is  considered  to  be  unrepairable  and  is  not  reported.  Combat  damage  is  the  third 
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Example  10.  Repairable  Item  Data  Table. 


entry  in  the  table.  If  combat  damage  repair  has  been  specified  for  this  asset,  then  "YES"  will 
be  printed  in  this  column,  otherwise  "NO"  combat  damage  repair  will  be  performed.  Next,  the 
penalty  for  repair  is  reported.  Penalty  is  the  loss  in  unit  effectiveness  that  will  be  accepted  in 
order  to  repair  the  damaged  asset.  The  mean  time  for  repair  is  the  next  datum  reported  in  the 
table.  Following  the  mean  time  entry  is  the  standard  deviation  (STD.  DEV.)  of  the  mean  time 
for  repair.  In  Example  10,  the  mean  time  of  repair  for  asset  number  80  (FORKLIFT  B)  is 
reported  as  60.0  min.  The  standard  deviation  of  the  mean  time  of  repair  for  the  forklift  asset 
is  reported  as  30.0  min. 

The  final  two  entries  reported  in  the  Repairable  Item  Data  Table  are  the  repair  location 
and  repair  construct  for  the  asset  group.  The  repair  location  is  simply  the  coordinates  of  the 
location  at  which  repair  of  the  item  at  the  reported  level  would  take  place.  The  repair 
construct  refers  to  the  number  of  the  construct  being  used  to  complete  the  repair. 

General  repair  is  an  option  used  to  specify  that,  in  order  to  perform  the  repair,  a  special 
link  is  needed.  This  link  may  not  necessarily  be  the  actual  repair  link  but  is  required  in 
addition  to  the  standard  repair  assets.  When  the  general  repair  option  is  used,  an  informative 
message  stating  the  general  repair  link  that  is  needed  to  perform  the  specified  levels  of  repair 
is  printed  following  the  tabulated  information  described  above.  In  Example  10,  general  repair 
messages  have  been  printed  for  level  1  and  level  2  repairs.  The  link  needed  for  both  levels  of 
repair  is  "*12,"  The  asterisk  preceding  the  number  indicates  that  the  construct  represents  a 
subchain. 

2.2.9  Parameters  for  Calculating  Heat  Stress  Table.  The  Parameters  for  Calculating  Heat 
Stress  Table,  illustrated  in  Example  1 1 ,  is  printed  only  when  modeling  heat  stress.  The  table 
is  divided  into  the  following  three  sections:  parameters  relating  to  personnel,  clothing 
parameters,  and  meteorological  condition  parameters.  These  parameters  are  user-specified 
under  the  HEAT  STRESS  command  (Klopcic,  Sheroke,  and  Price  1990).  AURA  uses  these 
parameters  in  conjunction  with  the  Goldman-Givoni  heat  stress  methodology  to  calculate  the 
effects  of  heat  stress  on  unit  personnel  (McNally.  Stark,  and  Ellzy  1990). 

The  first  section  of  the  Parameters  for  Calculating  Heat  Stress  Table  reports  the 
parameters  relating  to  personnel  (that  is,  skin  temperature  (°C),  percent  dehydration,  increase 


30 


PARAMETERS  FOR  CALCULATING  HEAT  STRESS 


PERSONNEL  PARAMETERS 

SKIN  TEMPERATURE  =  36.50 
PERCENT  DEHYDRATION  =  3.00 
INCREASE  IN  DEHY/DA  =  0.00 
DAYS  OF  ACCLIMATION  =  12.00 


CLOTHING  PARAMETERS 


MOH* 

CLO 

IM/CLO 

GAMMAC 

GAMMAI 

1 

1.13 

0.43 

0.26 

038 

2 

2.11 

0.23 

0.26 

038 

3 

1.13 

0.43 

0.26 

038 

4 

1.89 

0.16 

0.26 

038 

5 

1.13 

0.43 

0.26 

038 

6 

1.13 

0.43 

0.26 

038 

7 

1.13 

0.43 

026 

038 

8 

1.13 

0.43 

0.26 

038 

METEOROLOGY  VS.  TIME 

START  STOP  TEMP  HUMID  WIND  MMI 


OD  127500.0  36.67  mOO  3.00  9999.99 


MMA 


9999.99 


Example  11.  Parameters  for  CalculatinQ  Heat  Stress  Table 


in  dehydration  per  day,  and  days  of  acclimatization).  The  AURA  defaults  for  skin  temperature, 
percent  dehydration,  and  days  of  acclimation  are  36.0,  0.0,  and  12.0,  respectively.  The  user 
is  referred  to  the  previous  reference  for  a  comprehensive  explanation  of  AURA’S  heat  stress 
methodology  (McNally,  Stark,  and  Ellzy  1990). 

The  next  section  of  the  table  reports  tiie  clothing  parameters  for  each  MOPP  level  defined 
in  the  scenario  being  modeled.  Clothing  parameters  include  the  MOPP  level,  clothing  - 
insulative  properties  (CLO),  clothing  -  evaporation  properties  (IM/CLO),  wind  correction  factor 
for  insulative  properties  (GAMMAC),  and  wind  correction  factor  for  evaporative  properties 
(GAMMAI). 

Parameters  relating  to  the  meteorological  conditions  over  time  are  printed  in  the  third 
section  of  the  table.  The  items  reported  are  the  start  and  stop  times  for  the  meteorological 
time  period,  the  ambient  temperature  (TEMP)  (“C),  the  relative  humidity  (HUMID)  (0-100%), 
the  wind  speed  (WIND)  (m/s),  maximum  allowable  metabolic  rate  for  initial  MOPP  (MMI) 
(watts),  and  the  maximum-allowable  metabolic  rate  for  alternate  MOPP  (MMA)  (watts).  The 
default  values  for  these  parameters  are  as  follows: 

Meteorological  time  period  =  20.0  min 
Ambient  temperature  =  20.0®  C 
Relative  humidity  =  3.0% 

Maximum  metabolic  rate  (initial  MOPP)  =  1.E35  W 
Maximum  metabolic  rate  (alternate  MOPP)  =  1.E35  W 

2.2.10  Link  Definition  Table.  The  Link  Definition  Table,  illustrated  in  Example  12,  contains 
the  parameters  used  to  model  the  subtasks  which  can  be  performed  by  elements  of  the  unit 
specified  in  the  input  runstream.  This  information  can  be  used  by  the  analyst  to  reference  the 
initial  status  and  structure  of  each  link.  In  the  following  paragraphs,  this  table’s  contents  are 
defined  and  described.  The  first  column  of  this  table  contains  the  link  numbers  which  are 
assigned  to  each  link  by  AURA  according  to  the  order  that  the  links  are  input.  The  link  names 
are  listed  in  column  two.  Links  preceded  by  an  asterisk  denote  a  personnel  asset.  In  the 
bottom  row  of  the  Link  Definition  Table,  under  NAME,  is  the  NOT  IN  LINK  category.  This 
category  represents  assets  which  are  available  to  the  unit,  but  have  not  been  designated  as 
primary  assets  in  a  HOMELINK. 


32 


ir, 


■lyj'jflisn 


4iJM.,.iWJII!p!p.JJpS 


BP 


is 


gfe 

§“ 


t/i 


U) 


2e 


So 


bO  I 


3i 


56 

2« 


Xu. 

<  S 

•<  s 

s 


P6  I 
Ul  I 


hJ 


o 

X 


Q 


« 

SS 

£5  • 

Z  * 

>-]  • 


§§§§§ 

888S8 

c5  c>  c5  o  o 


o  o  o  o  o 


88888 

O  <d  C)  O  C) 


U  M  W  W  U 

zzzzz 

ooooo 

zzzzz 

QQ 

S^88S 

OP 

o®8S8 


88888 

o  o  o  o  <s 


88888 


o  g  r4  c4  00 


8888^ 

-rg  f'l  00 


ou 
v> 

s 

-So 

S-cs 


ss„ 

EEo 

•  «  * 


3| 

iS 

«  « 


8 

d 


u 

Z 

o 

z 

Q 

H 

s 

p 

Z 

P 

8 


8 

o 


8 


8^ 

18 


ON 

m 


—  c»  fO  ■v  «ri 


fn 

«o  «n 


33 


SLEEP  DEMND  -  Optimal  number  of  SLUNITs  required 

QUIT  EFF  -  Effectiveness  level  of  link  below  which  a  substitution  will  not  be  made  (Default:  0.100) 

METAB  RATE  -  Metabolic  rate  as  defined  in  input  runstream  (Default:  250.0) 

NOT  IN  LINK  -  The  number  of  items  deployed  which  have  no  primary  job 


In  the  third  column,  the  HOME  ID  number  of  the  link  is  shown.  This  number  is  the  internal 
number  of  the  assets  for  which  the  iink  was  named.  The  HOME  ID  number  is  assigned  by 
AURA  according  to  the  sequence  that  the  item  was  input  under  the  ASSET  section  of  the 
input  runstream.  Coiumn  four  contains  a  listing  of  the  number  of  items  deployed  and  available 
to  serve  each  link.  Note  that  the  DUMMYLINKs  are  designated  as  being  occupied  by  a 
negative  number  of  items.  The  number  of  substitutes  needed  to  reacfi  maximum 
effectiveness  is  the  number  foliowing  the  negative  sign.  For  example,  for  FIRETEAM,  the 
value  -20  means  that  it  is  a  dummy  link  and  it  needs  20  substitutes  to  reach  maximum 
effectiveness. 

In  the  fifth  column,  the  number  of  effective  assets  required  for  maximum  task  effectiveness 
(MAX  IN)  is  described.  The  ”MAX  EFF,"  which  is  the  maximum  effectiveness  attainable  by 
the  task,  appears  in  coiumn  six;  and  column  seven  represents  the  number  of  effective  assets 
required  for  minimum  task  effectiveness  (MIN  IN).  Column  eight  reports  the  minimum 
effectiveness  attainable  for  each  link  (MIN  EFF).  Column  nine  contains  MAX  iN  LINK,  which 
represents  the  maximum  number  of  assets  (regardless  of  individual  effectiveness)  which  can 
be  assigned  to  a  task. 

Column  ten  depicts  associated  links  (ASSOC  LINK).  An  associated  link  is  another  task 
whose  potential  fulfillment  controls  the  entities  assignable  to  the  current  task.  The  link 
granularity  (LNK  GRN)  is  listed  in  column  eleven.  AURA  provides  the  capability  to  allocate 
assets,  in  specified  fractional  portions,  to  more  than  one  job.  Column  twelve  shows  the  initial 
MOPP  degradation  value  (DGR  SET)  for  each  iink.  The  next  two  columns,  fatigue  rate 
(FATIG  RATE)  and  Sleep  demand  (SLEEP  DEMND)  contain  values  only  if  fatigue/sleep 
deprivation  effects  are  a  modeling  consideration.  The  fatigue  is  the  rate  at  which  assets  tire, 
and  sleep  demand  is  the  optimal  number  of  SLUNITs  required  by  these  personnel  assets.  A 
SLUNIT,  as  was  mentioned  previously,  is  a  unit  of  measure  used  to  represent  the  amount  of 
rest  associated  with  a  personnel  asset  (1  SLUNITs  1  min  of  fully  efficient  rest).  The  default 
values  for  fatigue  rate  and  sleep  demand  are  .2639  SLUNITs/min  and  1,235.0  SLUNITs, 
respectively. 

Column  fifteen  fists  the  QUIT  EFF  values  for  each  link.  This  value  is  the  effectiveness 
level  (default  value  is  0.100  or  10%)  of  the  link  below  which  a  substitution  will  not  be  made. 
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The  metabolic  rate  for  each  of  the  links  is  listed  in  the  iast  coiumn.  The  metaboiic  rate  default 
value  is  250.0  W,  which  correlates  to  the  energy  expenditure  of  a  person  performing  a  task  of 
medium  difficuity.  For  further  detaii  of  defauit  values  and  the  impact  of  other  heat  stress 
variables,  the  user  is  referred  to  the  Science  Applications  International  Corporation  (SAIC) 
report  (McNally.  Stark,  and  Ellzy  1990). 

2.2.1 1  Link  Status  Table.  Example  13  represents  the  next  AURA  output,  the  Link  Status 
Table.  For  each  asset  type,  the  links  (or  jobs)  in  which  the  members  of  the  asset  type  can 
serve  are  shown.  The  letter  "H"  stands  for  HOMELINK,  which  is  the  primary  job  of  the  asset 
in  which  it  can  immediately  senre  with  100%  effectiveness.  An  entry  of  the  form  time/ 
effectiveness/order  indicates  a  job  into  which  an  asset  can  substitute  in  the  time  amount 
(minutes)  and  with  the  corresponding  effectiveness  value.  The  order  number  indicates  the 
sequence  in  which  the  user  specified  the  substitutes  and  is  used  to  choose  one  particular 
substitute  over  another  if  all  other  quantities  (namely  versatility  and  effectiveness)  are  equal. 
Finally,  a  blank  entry  indicates  that  no  substitution  is  possible  for  the  link. 

2.2.12  Subchains,  Oriinks,  Compound  (CP)  Links,  and  Chains.  Examples  14-17  are 
reiterations  of  the  unit’s  inputs  for  subchain  elements,  orlink  branches,  compound  link  parts, 
and  chain  segments.  These  tables  are  used  primarily  to  reference  the  configurations  of  these 
unit  tasks  being  modeled.  Recall,  subchains  are  used  to  represent  the  combinations  of  unit 
tasks  which  must  be  performed  in  conjunction  to  accomplish  a  more  complex  mission  tasking. 
Oriinks  are  used  to  represent  mutually  exclusive  choices  for  the  accomplishment  of  part  of  the 
mission.  Compound  links  are  used  to  represent  several  groups  tasks/jobs  such  that  the  total 
activity  is  a  summation  of  the  independent  contributions  of  the  different  constructs.  A  chain  is 
a  collection  of  AURA  constructs  which  span  the  activities  of  a  unit  to  represent  the  unit 
mission.  These  tables  serve  to  verify  the  correctness  of  the  inputs  by  allowing  the  analyst  to 
view  the  unit  structures  to  ensure  the  intended  task  configurations. 

(1)  Elements  in  Each  Subchain  Table.  The  Elements  in  Each  Subchain  Table  is  illustrated 
in  Example  14.  The  table  consists  mainly  of  two  columns  headed  by  "SUBCHAIN"  and 
"ELEMENTS."  The  subchain  numbers  are  listed  under  the  first  header,  "SUBCHAIN," 
and  are  sequenced  according  to  the  order  listed  in  the  input  runstream.  In  AURA, 
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ELEMENTS  IN  EACH  SUBCHAIN 


SUBCHAIN  ELEMENTS 


•I 

FRKLFT6A 

OPERATOR  A 

*2 

FRKLFT6B 

OPERATOR B 

•3 

FRKLFT6C 

OPERATOR  C 

•4 

FRKLFT6D 

OPERATOR  D 

•5 

FRKLFT6E 

OPERATOR E 

•6 

FRKLFT6F 

OPERATOR F 

•7 

FRKLFT6G 

OPERATOR  G 

*8 

FRKLFTdl 

OPERATOR  J 

•9 

FRKLFT4K 

OPERATOR  K 

•10 

FRKLFT4L 

OPERATOR  L 

•11 

FRKLFT4M 

OPERATOR  M 

•12 

CRANE 

CRANE  OPER 

•13 

RECORD  CLERK 

RECORDS 

Example  14.  Elements  in  Each  Subchain  Table. 


UFT/LOAD  OP 
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subch£dn  names  are  designated  by  a  preceding  ***.  The  second  header, 

"ELEMENTS,"  contains  the  elements/tasks  of  each  subchain  listed  horizontally. 

Only  five  elements  are  listed  per  line.  Any  subsequent  elements  for  the 
subchain  are  listed  on  the  following  line. 

(2)  Branches  in  Each  Ortink  Table.  Example  15  illustrates  the  Branches  in  Each  Oriink 
Table.  The  entries  in  this  table  are  denoted  by  the  column  headers  "ORLINK"  and 
"BRANCHES."  The  oriink  numbers  are  listed  under  the  first  header,  "ORLINK,"  and 
are  sequenced  to  ttie  order  listed  in  the  input  runstream.  In  AURA,  oriink  names  are 
designated  by  a  preceding  "+".  The  remainder  of  the  table  contains  the  "BRANCHES" 
for  the  orlinks.  Each  column  contains  one  branch  and  indicates  an  alternative  for 
accomplishing  a  task.  The  first  branch  column  is  composed  of  subchains  1-1 1 , 
described  in  the  preceding  paragraph  and  shown  in  Example  14.  The  second  branch 
column  is  composed  of  "USERS."  Therefore,  for  each  of  the  eleven  orlinks  listed, 
AURA  may  choose  a  subchain  and  its  respective  elements  or  a  USER  to  accomplish 
the  assigned  task. 

(3)  Parts  in  Each  Compound  Link  Table.  The  next  table  found  in  the  output  is  the  Parts  in 
Each  Compound  Link  Table.  This  table  is  illustrated  in  Example  16.  The  format  of  this 
table  is  like  that  of  the  previous  two  tables,  in  that  the  table  consists  msdniy  of  two 
entries,  each  designated  by  the  column  headers  "CP  LINK"  and  "CP  PARTS."  There  is 
only  one  compound  link  in  this  unit,  and  its  name  is  listed  under  the  "CP  LINK"  header 
as  "IMHE."  MHE  stands  for  "materials  handling  equipment"  In  AURA,  compound  link 
names  are  designated  by  a  preceding  "I".  The  second  header,  "CP  PARTS,"  contains 
the  parts  of  the  compound  link  listed  horizontally.  After  five  compound  link  parts  are 
listed  across  the  page,  the  sixth  part  starts  a  new  line  and  so  on  until  the  complete 
compound  link  is  graphically  described.  The  twelve  parts  of  this  compound  link  are 
orlinks  as  designated  by  the  "-t-"  preceding  the  number.  Compound  links  are  each 
contribute  slightly  over  6%  (.063)  toward  the  compound  link  task.  (Note  that  Example 
16  only  reports  compound  link  part  weights  to  two  significant  digits  [i.e.,  .06  instead  of 
.063]).  Part  No.  12  contributes  the  remaining  31%  necessary  to  satisfy  the  compound 
link  requirement  for  the  parts  to  sum  to  100%. 
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BRANCHES  IN  EACH  ORUNK 


ORLINK 

BRANCHES 

+1 

*1 

USERS  A 

+2 

*2 

USERS B 

+3 

*3 

USERS C 

+4 

•4 

USERS D 

+5 

•5 

USERS E 

+6 

•6 

USERS? 

+7 

•7 

USERS  G 

+8 

•8 

USERS! 

+9 

•9 

USERS K 

•1-10 

•10 

USERS L 

-t-ll 

•11 

USERS M 

Example  15. 

Branches  in  Each  Ortink  Table. 
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(4)  Segments  in  Each  Chain  Tabie.  The  finai  tabie  of  this  section  is  entitied 
"Segments  in  Each  Chain"  and  is  shown  in  Example  17.  The  primary  column 
header  is  "CHAINS."  In  this  unit  example,  only  one  chain  is  being  modeled. 

The  typical  AURA  unit  description  contains  only  one  chain;  however,  AURA  is 
capable  of  modeling  multiple  chains.  This  chain  has  eight  segments  and  the 
numbers  1-8  are  listed  under  the  abbreviation  "SEG"  in  the  table  header. 

Under  the  number  "1 "  in  the  header  are  the  names  of  the  seven  segments  of 
chain  1 .  The  first,  second,  and  fourth  through  sixth  segments  are  links.  The 
third  and  eighth  segments  are  subchains  as  designated  by  the  """  preceding  the 
subchain  number.  The  seventh  segment  is  a  compound  link  designated  by  the 
"!"  preceding  the  compound  link  name.  If  more  than  one  chain  were  to  be 
modeled,  the  segments  of  the  second  chain  would  have  been  listed  under  the 
number  "2"  in  the  table  header. 

2.2.13  Chain  Plot.  Example  18  is  a  line-printer  depiction  of  the  functional  structure  of  a 
chain.  This  chain  represents  the  Ammunition  Supply  Point  (ASP),  which  is  responsible  for 
establishing  and  operating  ammunition  supply  facilities  for  the  receipt,  storage,  rewarehousing, 
and  issue  of  conventional  ammunition.  This  particular  chain  is  composed  of  segments 
comprised  of  several  links,  a  subchain,  and  one  compound  link  composed  of  several  orlinks 
and  subchains.  In  this  figure,  different  kinds  of  horizontal  lines  of  characters  are  used  to 
identify  the  functional  structures:  exclamation  points  (!)  for  compound  links,  asterisks  (*)  for 
subchains,  and  plus  signs  (+)  for  orlinks.  The  (@)  signs  simply  serve  to  graphically  connect 
the  segments  into  a  chain.  Each  segment  represents  a  subtask  defining  a  portion  of  the 
overall  mission  and  is  composed  of  both  personnel  and  equipment  assets. 

The  first  two  segments  listed  are  links.  The  two  links  are  each  composed  of  one  item. 

One  has  a  chief  ammunition  inspector,  and  the  other  has  an  ammunition  clerk.  These  items 
are  listed  as  CH  AMMO  INSP  and  AMMO  CLERK,  respectively.  These  two  segments  are 
responsible  for  supervising  the  ammunition  checkers  and  keeping  records  on  how  many  items 
of  ammunition  are  rejected  and  shipped  out.  The  third  segment  is  a  subchain  composed  of 
two  elements,  a  record  clerk  and  records,  listed  as  RECORD  CLERK  and  RECORDS, 
respectively.  This  segment  is  responsible  for  keeping  track  of  all  the  incoming  shipments. 
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SEGMENTS  IN  EACH  CHAIN 
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1  .  CH  AMMO  INSP 

2  .  AMMO  CLERK 

3  .  *13 

4  .  CHECKERS 

5  .  CRANE  CHIEF 

6  .  RTFL  CHIEF 

7  .  IMHE 

8  .  *12 
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PLOT  OF  CHAIN  #  1  OHERANT  TIMES :  (  0.0  -  INF. 
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Example  18.  Chain  Plot,  (continued) 


outgoing  shipments,  and  other  types  of  pertinent  records.  The  next  three  segments  are  links 
with  each  composed  of  one  item.  These  three  items  are  ammunition  checkers,  a  crane  chief, 
and  a  rough  terrain  forklift  chief.  These  items  are  listed  as  CHECKERS,  CRANE  CHIEF,  and 
RTFL  CHIEF,  respectively.  These  three  segments  are  responsible  for  inspecting  the 
ammunition  for  defects,  supervising  the  crane  operations,  and  supervising  the  forklift 
operations. 

The  seventh  segment  is  a  compound  link,  which  is  responsible  for  loading  trucks  with 
ammunition.  This  compound  link  is  composed  of  twelve  parts.  The  first  eleven  are  orlinks, 
each  composed  of  two  branches.  The  first  branch  contains  a  forklift  and  a  forklift  operator 
which  are  elements  of  subchains.  The  second  branch  of  each  orlink  contains  manual  loading 
personnel  (USERS).  (See  also  Examples  14  and  15  and  their  respective  descriptions  for 
more  explanation.)  The  eleven  forklifts  are  listed  as  FRKLFT  plus  one  of  the  following 
number-letter  combinations;  6A,  6B,  6C,  6D,  6E,  6F,  6G.  6J,  4K,  4L,  and  4M.  Similarly,  the 
forklift  operators  are  listed  as  OPERATOR,  plus  one  of  these  letters:  A.  B.  C.  D,  E,  F,  G,  J, 

K,  L,  and  M.  In  this  particular  example,  each  is  responsible  for  a  different  category  of 
ammunition.  The  loading  personnel  are  listed  as  USERS  and  are  followed  by  the  same  letters 
as  the  operators.  These  1 1  orlinks  are  responsible  for  loading  the  trucks  with  the  majority  of 
the  ammunition  stacks.  This  task  can  be  accomplished  mechanically  (with  forklifts)  or 
manually  (by  operators)  in  case  of  forklift  failure.  Each  of  these  orlinks  is  assigned  an 
independent  weighted  contribution  value  of  0.063.  When  operational,  each  of  these  orlinks 
contributes  a  maximum  of  6.3%  to  the  overall  effectiveness  of  the  task  represented  by  the 
compound  link.  For  this  chain  plot,  this  value  is  listed  only  to  two  decimal  places  to  the  right 
of  the  decimal  point  (0.06)  and  rounded  up  to  two  significant  digits. 

The  twelfth  part  of  this  compound  link  is  a  subchain  (denoted  by  asterisks)  composed  of 
three  elements:  a  crane,  a  crane  operator,  and  a  lift/load  operator.  These  elements  are  listed 
as  CRANE,  CRANE  OP,  and  LIFT/LOADOP,  respectively.  This  subchain  is  responsible  for 
loading  the  heavier  ammunition  stacks  onto  the  trucks.  The  contribution  of  this  part  can  be  at 
most  0.307,  which  has  been  rounded  to  0.31  on  ttie  plot. 

The  chain  plot  is  primarily  used  as  a  quick  reference  as  to  the  overall  organization  of  unit 
tasks.  In  the  analysis  of  unit  effectiveness  it  is  often  necessary  to  assess  the  weak  segment 
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or  choke  point.  This  chain  plot  provides  a  graphic  display  of  unit  constructs  in  the  order  in 
which  the  code  will  follow  to  determine  the  weak  segment  or  choke  point.  If  two  choke  points 
occur,  the  one  encountered  first  will  be  identified  in  the  Weak  Link  Table.  (See 
"Reconstitution”  in  the  Intermediate  Results  section  of  this  report.) 

2.2.14  Deployment.  Example  19  summarizes  the  deployment  parameters  for  posture  and 
location  defined  for  each  AURA  asset  in  the  input  runstream.  The  assets  in  the  deployment 
table  are  printed  according  to  the  sequential  order  of  each  point. 

The  first  column  of  the  Deployment  Table  is  the  target  point.  AURA  internally  sorts  all 
target  points  and  reports  the  assets  (and  their  corresponding  parameters)  deployed  at  each 
target  point.  The  second  column  contains  the  identification  number  assigned  to  each  asset 
based  upon  the  input  order  of  the  input  runstream.  Column  three  contains  the  alphanumeric 
name  of  the  asset.  An  asterisk  preceding  the  asset  name  indicates  a  personnel  asset. 

Column  four  represents  the  identification  number  of  the  link/job  associated  with  each  asset. 
The  link  numbers  are  assigned  by  AURA  based  upon  the  order  that  the  links  are  input. 
Columns  five  and  six  represent  the  Cartesian  grid  coordinates  of  the  target  point.  Column  five 
is  the  X  coordinate,  and  column  six  represents  the  Y  coordinate.  The  next  column  entry 
represents  the  number  of  assets  which  are  deployed  at  the  target  point.  A  minus  sign 
preceding  the  value  in  this  column  signifies  that  the  assets  at  this  target  point  are 
DUMMYLINKs.  DUMMYLINKs  are  jobs  that  may  be  deployed  but  have  no  primary  assets 
associated  to  them.  DUMMYLINKs  may  be  used  if  the  scenario  warrants  the  use  of  additional 
or  alternative  methods  to  complete  tasks  within  the  mission.  Columns  eight  through  ten  report 
the  kill  criteria  (KC)  for  conventional,  nuclear,  and  chemical  environments,  respectively.  The 
user  is  referred  to  the  AURA  Input  Manual  for  a  detailed  discussion  of  these  parameters 
(Klopcic,  Sheroke,  and  Price  1990).  Columns  eleven  through  thirteen  represent  the  posture 
code  number  associated  with  each  lethality  type  (i.e.,  conventional,  nuclear,  and  chemical, 
respectively).  In  AURA,  an  asset  may  be  described  to  be  in  one  of  several  postures  such  as 
in  the  open,  in  a  foxhole,  in  a  tank,  etc.  AURA  can  assess  weapon  effects  criteria  based  upon 
the  asset’s  battlefield  posture.  The  default  asset  posture  is  one  which  represents  an  "in  the 
open"  battlefield  posture  and  can  be  modified  via  the  DEPLOYMENT  command.  AURA 
provides  the  capability  for  the  user  to  specify  postures  for  any  battlefield  environment 
scenario.  Some  example  postures  used  in  AURA  analyses  have  been  "behind  a  building,"  "in 
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a  dense  forest."  and  "in  a  tent."  These  postures  must  be  assigned  a  posture  code  value  and 
associated  criteria  by  the  knowledgeable  user. 

Columns  fourteen  through  eighteen  are  only  printed  when  alternate  duck  or  MOPP 
postures  are  being  specified  within  the  input  runstream.  Coiumn  fourteen,  prefaced  by  the 
label  "DUCK  TIME."  reports  the  time  required  for  the  asset  to  change  from  its  originai  to  its 
alternate  posture.  Duck  ^me  is  an  analogy  to  the  natural  reaction  of  a  person  to  "take  cover" 
or  duck  upon  the  detonation  of  a  warhead.  Duck  time  only  refers  to  the  posture  changes  for  a 
conventional  or  nuclear  scenario.  It  is  important  to  understand  the  distinction  between  coiumn 
fourteen  (DUCK  TiME)  and  column  eighteen  (MOPP  TiME).  DUCK  TIME  reports  the  time 
required  to  change  postures  for  conventional  or  nuclear  environments  while  MOPP  TIME  only 
reports  the  time  required  for  posture  change  associated  with  a  chemical  scenario. 

Coiumns  fifteen  through  seventeen  report  the  alternate  postures  for  conventional,  nuclear,  and 
chemical  as  defined  by  the  vaiues  specified  in  the  DEPLOYMENT  command. 

2.2.15  Deployment  Plot.  Example  20  is  a  line-printer  plot  of  an  example  unit  deployment. 
The  deployment  plot  depicts  the  location  of  all  assets  deployed  in  the  unit. 

Asset  group  items  are  represented  by  their  two-digit  identification  (ID)  numbers  which  have 
been  assigned  by  AURA  and  are  determined  by  the  order  that  the  assets  are  sequenced  in 
the  input  runstream.  Asset  iD  numbers  1-9  are  represented  by  a  preceding  zero.  The 
depioyment  piot  is  mapped  to  an  inverted  Cartesian  coordinate  system  in  which  the  Y  axis  is 
the  horizontal  axis  and  the  X  axis  is  the  vertical  axis.  If  two  or  more  assets  are  deployed  at 
the  same  target  point,  they  are  shown  adjacent  to  each  other  in  the  piot.  For  this  reason,  the 
depioyment  piot  is  not  a  scaied  drawing  of  the  unit  and  shouid  oniy  be  used  as  a  quick  check 
of  the  data.  (Note:  Utiiity  graphics  programs  such  as  AURATEK  [Swoboda  1991]  exist  to 
produce  scaled  drawings  of  AURA  inputs.)  These  numbers  and  their  corresponding  assets 
are  shown  in  Example  19,  the  Deployment  Table. 

The  deployment  plot  also  indicates  the  incoming  fire  direction  and  wind  direction.  In  this 
example,  the  incoming  fire  direction  is  from  east  to  west  and  is  shown  by  the  path  from  the 
AAs  toward  the  BBs.  The  wind  direction  is  also  from  east  to  west  and  is  described  by  the 
path  shown  by  the  iine  from  YY  to  ZZ. 
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Example  20.  Deployment  Plot. 
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Example  20.  Deployment  Plot,  (continued) 


As  referenced  before,  the  Y  axis  is  the  horizontai  axis,  and  the  X  axis  is  the  vertical  axis. 
This  is  depicted  in  ttie  first  line  of  the  plot,  after  the  header  "DEPLOYMENT,"  as  "Y  INTERVAL 
«  600.  X  INTERVAL  =  50."  "Y  INTERVAL  =  600."  means  that  each  greater  than  sign  on  the 
Y  axis  is  displayed  in  increments  of  600.  Likewise.  "X  INTERVAL  «  50."  signifies  that  each 
greater  tfian  sign  on  the  X  axis  is  displayed  in  increments  of  50.  Also  stated  in  line  1  is  the 
incoming  fire  direction  and  wind  direction,  depicted  as  "INITIAL  INCOMING  DIRECTION 
FROM  AA  TO  BB  DOWNWIND  FROM  YY  TO  ZZ."  The  next  line  displays  the  Y  axis,  and  the 
first  column  displays  the  X  axis.  In  Example  20,  the  target  point  (463,1506)  shows  a  dense 
asset  population.  This  list  of  numbers,  484337523535663545373533,  is  composed  of  the 
two-digit  tD  numbers  48.  43.  37,  52.  35,  35.  66,  35,  45,  37,  35,  and  33.  The  deployment  plot 
produced  in  this  example  would  be  interpreted  in  the  following  manner:  move  supervisor, 
ammunition  technician,  trailer,  van5ton,  radio,  radio.  ASP  platoon  leader,  radio,  record  clerk, 
trailer,  radio,  and  guard.  The  deployment  table  (described  in  the  previous  section)  was  used 
to  identify  these  numbers  with  their  corresponding  assets.  (Note:  not  all  identification 
numbers  in  the  unit  are  shown  in  Example  19). 

2.3.  Intermediate  Results. 

2.3.1  Nuclear/Chemical  Dosage  Accumulation  Table.  The  Dosage  Accumulation  Table 
reports  the  nuclear  or  chemical  dosages  received  by  personnel  assets.  In  AURA,  the 
dosages  received  are  accumulated  with  respect  to  the  target  point.  That  is,  the  personnel 
assets  receive  the  same  dosage  as  the  target  point.  The  three  values  reported  by  the 
Dosage  Accumulation  Table  are  as  follows:  the  amount  of  nuclear  or  chemical  dosage 
received,  the  time  that  the  dosage  was  received,  and  the  resiliency  (or  hardness  factor)  to  the 
dosage  associated  with  each  individual.  In  a  nuclear  scenario,  the  dosage  received  is 
reported  in  units  of  rads  (cGy),  while  chemical  dosages  will  be  reported  in  milligrams  minute 
per  cubic  meter  (mg.min/m®)  (vapor  agent)  or  milligrams  per  square  meter  (mg/m®) 
(percutaneous  agent).  The  hardness  factor  is  a  number  between  the  values  of  0.0  and  1 .0, 
selected  at  random  by  AURA,  which  is  used  to  indicate  the  resiliency  of  an  individual  affected 
by  a  specified  dose.  The  inclusion  of  personnel  hardness  values  provides  a  modeling  tool  to 
represent  the  variance  in  how  personnel  are  affected  by  nuclear  or  chemical  dosages.  The 
greater  the  hardness  value,  the  less  resilient  the  asset  is  toward  the  nuclear/chemical  dosage. 
For  example,  if  a  person  is  assigned  a  hardness  value  of  .57,  the  total  dosage  assigned  to 
this  person  will  be  calculated  as  the  product  of  .57  and  dosage,  which  means  that  this  person 


will  receive  57%  of  the  dosage.  This  information  is  used  by  the  analyst  to  determine  which 
assets  will  be  more  susceptible  to  the  doses  received. 

Example  21a  illustrates  the  Dosage  Accumulation  Table  for  a  nuclear  scenario.  The 
reporting  time  in  this  case  is  30.0  min  into  the  scenario,  shown  by  the  string  "DOSAGE  BINS 
AT  TIME  30.0."  The  data  reported  in  the  table  are  as  follows:  the  asset  group  identification 
number,  the  number  of  assets  in  that  asset  group,  and  the  dosage  information.  In  this 
example,  there  are  two  people  in  asset  group  No.  16  who  received  340  rads  at  8  min  into  the 
scenario,  and  their  hardness  value  is  0.263. 

Example  21b  illustrates  the  Dosage  Accumulation  Table  for  a  chemical  scenario.  The 
reporting  time  in  this  case  is  20.0  min  into  the  scenario,  shown  by  the  string  "DOSAGE  BINS 
AT  TIME  20.0."  The  data  reported  in  the  table  are  as  follows:  the  asset  group  identification 
number,  the  number  of  assets  in  that  asset  group,  and  the  chemical  dosage  information. 
Assuming  that  the  agent  is  a  vapor  in  this  example,  the  two  assets  in  asset  group  No.  19 
received  a  vapor  dosage  of  1 .4  mg.min/m^  at  5  min  into  the  scenario.  The  hardness  value 
associated  with  these  personnel  is  0.870. 

2.3.2  Casualties.  The  casuaity  outputs,  illustrated  in  Examples  22-27,  are  printed  as  a 
result  of  the  declaration  of  the  CASUALTIES.ON  option  within  the  input  runstream.  This 
output  option  causes  a  report  of  all  casualties,  contaminations,  early  transient  incapacitation 
(ETI)  episodes,  and  expenditures  as  they  occur.  In  addition,  the  use  of  the  CASUALTIES 
option  also  causes  reports  of  equipment  reliability  failures  and  heat  stress  losses.  If  the 
WEAPON.ON  option  has  not  been  issued,  the  CASUALTIES  option  also  describes  incoming 
warheads  which  cause  immediate  casualties.  (For  an  explanation  and  illustration  of  tiiis 
output,  the  user  is  referred  to  the  WEAPON  section  of  this  report.)  Output  for  the 
CASUALTIES  option  differs  depending  on  the  environment  being  modeled  (i.e.,  conventional, 
chemical,  or  nuclear).  Examples  of  the  various  outputs,  produced  by  the  CASUALTIES.ON 
option,  are  given  and  explained  in  the  following  paragraphs. 

The  Casualty  Table  resulting  from  a  conventional  run  (illustrated  in  Example  22)  begins  by 
listing  the  asset  group  identification  number  and  the  corresponding  link  with  which  the  asset  is 
associated.  Next,  the  probability  of  damage  (PKF)  is  reported.  PKF  is  the  total  probability  of 
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(NUCLEAR) 

DOSAGE  BINS  AT  TIME  30.00 

tit******************************* 


ID  NUMBER  AT  ( DOSE /TIME -OF- DOSE /HARDNESS )... . 


16 

2.00 

(  340.0 

/ 

8.0  /  0.263  ) 

17 

1.00 

( 

0. 
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0.  /  0.471  ) 

18 

1.00 

( 
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0.  /  0.054  ) 

19 

1.00 
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0.  /  0.870  ) 

(a)  Nuclear 


(CHEMICAL) 

DOSAGE  BINS  AT  TIME  20.00 
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2.00 
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1.4  / 

5.0  /  0.870  ) 

17 

1.00 
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0.  / 

0.  /  0.263  ) 

18 

1.00 

( 

0.  / 

0.  /  0.672  ) 

19 

1.00 
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0.  / 

0.  /  0.107  ) 

(b)  Chemical 


Example  21 .  Nuclear  and  Chemical  Dosage  Accumulation  Table. 
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tight,  mecfium,  and  heavy  damage  (otherwise  referred  to  as  indusive  damage  tevets)  for  ttie 
spedfied  asset  group.  In  the  first  line  of  Example  22,  the  PKF  for  asset  group  9  is  1 .00.  That 
is.  the  total  probability  of  damage  for  asset  group  No.  9  is  100%.  The  remaining  information 
reported  pertains  to  the  number  of  assets  lost  within  the  given  asset  group.  Probability  of  kill 
is  described  with  respect  to  the  target  point  and  corresponding  coordinates  specified  for  each 
asset  group  in  the  depioyment  section  of  the  input  runstream.  The  first  line  of  Example  22 
shows  that  asset  group  No.  9  at  target  point  96  (which  has  the  coordinates  150.0, 110.0)  lost 
a  total  of  0.34  members. 

When  modeling  a  chemical  attack,  the  CASUALTIES.ON  option  results  in  several  different 
outputs,  some  of  which  pertain  only  to  equipment  assets  while  others  apply  only  to  personnel. 
The  first  group  of  casualty  results,  described  in  the  following  paragraph,  consists  of  three 
types  of  outputs  relating  to  equipment  contamination.  The  subsequent  two  paragraphs 
contain  the  detailed  description  of  the  outputs  relating  to  the  effects  of  chemical  munitions  on 
personnel. 

The  first  contamination  output,  shown  in  Example  23a,  lists  the  time  (in  minutes)  at  which 
the  contamination  occurred  and  the  number  of  items  contaminated  by  the  chemical  hazard.  In 
AURA,  the  criterion  for  being  considered  contaminated  Is  based  on  the  minimum  level  of 
contamination  specified  in  the  PRETOX  run  (Hindman  1990).  As  in  the  case  of  a  conventional 
scenario,  the  casualty  report  for  each  asset  group  is  given  with  respect  to  the  associated 
target  point.  The  target  point  and  corresponding  coordinates  are  the  next  items  reported  in 
the  output.  The  next  data  reported  is  the  HOME  ID  (i.e.,  HOMELINK  identification  number)  of 
the  affected  target  point.  The  last  item  reported  is  the  evaporation  time  (EVAP  TIME). 
Evaporation  time  is  the  clock  time  at  which  the  chemical  contaminate  will  evaporate  to  the 
minimum  contamination  level  specified  by  the  user  in  NUSSE  (Saucier  1986).  In  the  event 
that  a  previously  contaminated  item  is  recontaminated,  a  message,  following  the  output 
described  above,  will  be  printed  (see  Example  23b).  This  message  reports  the  number  of 
assets  that  have  been  recontaminated  followed  by  the  phrase  "PREVIOUSLY 
CONTAMINATED  ITEMS  WERE  RECONTAMINATED."  AURA  reports  the  recontamination 
status  to  describe  why  some  assets,  whose  contamination  should  have  evaporated,  continue 
to  have  a  contaminated  status.  In  other  words,  additional  contamination  received  by  an  asset 
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(Chemical  -  contamination  output) 
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Example  23.  Casualties  -  Chem  1 . 


which  has  already  begun  the  decontamination  process  will  increase  the  time  necessary  for 
that  asset  to  be  decontaminated. 

The  CASUALTIES, ON  option  will  also  cause  a  report  of  assets  that  have  been 
decontaminated.  This  portion  of  output  (illustrated  in  Example  23c)  lists  the  time  in  the 
simulation  at  which  the  asset  was  decontaminated.  The  remainder  of  this  output  is  preceded 
by  the  phrase,  "JUNK  FROM  ID,"  which  introduces  the  group  identification  number  for  the 
decontaminated  asset.  The  word  "JUNK"  refers  to  the  pool  of  contaminated  assets.  The 
phrase,  "WAS  EVAPORATION  DECONNED,"  completes  this  portion  of  output.  Evaporation 
deconned  means  that  sufficient  time  has  elapsed  so  that  the  effects  of  the  contaminating 
agent  have  evaporated.  Once  the  previously  contaminated  assets  become  evaporation 
deconned,  they  are  ready  to  be  used  and  are  reassigned  to  the  pool  of  available  assets. 

Another  type  of  chemical  casualty  output  is  the  dose-time  casualty  report.  In  the  context 
of  this  table,  a  dose-time  casualty  is  defined  as  an  individual  who  has  received  a  lethal  dose, 
and  for  which  the  time  required  for  the  dosage  to  take  effect  has  elapsed.  The  corresponding 
output  (illustrated  in  Example  24a)  begins  by  listing  the  time  at  which  the  asset  became  a 
casualty.  Next,  the  group  identification  number  followed  by  the  total  number  of  casualties  for 
the  affected  asset  group  is  listed.  The  last  items  printed  are  ttie  cumulative  dose  (DOSE),  the 
dosage  multiplier  (MULT)  (see  T.K.C.  mnemonic  in  the  AURA  Input  Manual  for  more 
information),  and  the  time  (TIME)  over  which  the  dosage  was  received. 

The  last  type  of  casualty  possible  in  a  chemical  scenario  is  an  immediate  casualty.  This 
type  of  casualty  is  incurred  when  a  personnel  asset  receives  sufficient  toxic  dosage  over  a 
short  time  period  to  be  considered  a  casualty  based  on  a  specified  maximum  dose  criterion. 
Example  24b  illustrates  the  output  for  immediate  casualties  which  also  begins  by  listing  the 
time  at  which  the  casualty  occurred  followed  by  the  identification  number  of  the  affected  asset 
group.  The  final  entry  is  the  total  immediate  casualties  received  by  the  asset  group. 

For  nuclear  scenarios,  there  are  several  types  of  outputs  reported  for  the 
CASUALTIES, ON  option.  The  first  way  in  which  a  nuclear  casualty  may  be  reported  is  with 
respect  to  the  asset's  susceptibility  to  the  various  environments  created  by  a  nuclear  weapon 
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(Giemical  •  casualty  output ) 
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Example  24,  Casualties  -  Chem  2. 


(i.e.,  blast  [BUST],  electromagnetic  pulse  [EMP],  njeutron  fluence  [NF]  (sometimes  referred  to 
as  transient  radiation  effects  on  electronics),  and  thermal  fluence  [THRM]).  Effects  from  these 
four  environments  are  reported  for  equipment.  Of  these  four  environments,  personnel  are 
only  susceptible  to  the  effects  of  blast  and  thermal  fluence;  consequently,  only  parameters 
relating  to  these  environments  are  reported  for  pereonnel  assets.  (It  should  be  noted  that 
personnel  are  also  susceptible  to  radiation.  When  using  the  CASUALTIES,ON  option, 
radiation  effects  are  reported  in  separate  outputs,  namely  the  dose-time  casualty  and 
immediate  casualty  outputs.  These  outputs  are  illustrated  and  explained  below.)  The  output 
generated  (illustrated  in  Example  25)  begins  by  listing  the  asset  group  identification  number, 
followed  by  the  link  (LNK)  in  which  the  asset  group  is  deployed.  Next,  the  probability  of  kill 
(PK)  for  assets  of  this  type  is  listed.  Following  the  PK  is  the  probability  of  kill  multiplied  by  the 
number  of  assets  (PK*number)  deployed  at  the  specified  target  point. 

When  the  casualty  reported  is  an  equipment  asset  (i.e.,  damaged  equipment),  the 
probability  of  survival  with  respect  to  each  environment  is  listed  in  the  following  form: 
(environment  "dosage7probability  of  survival)  for  blast,  electromagnetic  pulse,  neutron  fluence, 
and  thermal  fluence,  respectively.  The  units  for  the  various  environments  are  psi*  sec,  volts 
per  meter  (V/m),  neutrons/cm*,  and  cal/cm*,  respectively.  In  Example  25,  asset  group  No.  4 
of  link  No.  9  has  the  probability  of  kill  (PK)  equal  to  0.98.  The  probability  of  kill  times  the 
number  of  assets  of  this  asset  type  at  target  point  No.  2,  with  the  coordinates  1356.0  and 
1739.5,  is  0.98.  (In  this  case,  there  is  only  one  asset  of  this  type  deployed  at  target  point 
No.  2  since  the  PK  for  this  asset  group  No.  9  is  the  same  as  the  value  of  the  PK  multiplied  by 
the  number  of  assets  at  the  target  point  [PK*#].)  Foilowing  this  data,  the  probability  of  survival 
with  respect  to  the  various  environments  is  reported.  In  Example  25,  the  blast, 
electromagnetic  pulse,  and  thermal  fluence  level  are  reported  as  O.OOE+00.  This  simply 
means  that  no  effects  from  these  environments  were  calculated  for  this  asset.  However,  in 
the  case  of  the  neutron  fluence  environment,  ttie  effect  received  was  2.52E+12  (or  2.52  X 
10’^  neutrons/cm^  Consequently,  in  this  environment,  the  asset  only  has  a  0.02  (2%)  chance 
of  survival. 

In  the  case  of  personnel  assets,  the  probability  of  kill  with  respect  to  the  blast  and  thermal 
environments  is  reported.  In  Example  25,  the  fourth  entry  is  read  as  follows:  asset  group  No. 
17  of  link  No.  9  has  the  probability  of  kill  equal  to  1.00  (100%).  The  probability  of  kill 
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multiplied  by  the  number  of  personnel  of  this  asset  type  at  target  point  10  with  the  coordinates 
1349.0  and  1292.2  is  2.00.  (in  other  words,  there  are  two  personnel  assets  deployed  at  this 
target  point.)  The  probabiiity  of  kiii  due  to  the  blast  received  (19.14  psi^  sec)  is  0.26  (26%). 
The  probability  of  kiil  with  respect  to  the  level  of  thermal  fluence  received  (76.48  cal/cm^  is 
1.00  (100%).  From  this  information,  the  analyst  can  determine  that  thermai  fiuence  was  the 
dominant  effect.  The  third  environment  to  which  personnel  are  susceptible  is  radiation  which 
is  reported  via  the  DOSE  output  option.  Casualties  resulting  from  these  dosages  are 
controlled  by  the  CASUALTIES,ON  option. 

Example  26a  depicts  the  nuciear  scenario  casualty  report  for  an  accumulated  dose-time 
casualty.  This  type  of  casualty,  as  the  name  implies,  resuits  when  a  personnel  asset  receives 
a  sufficient  nuclear  dose  (rads)  to  cause  death  within  a  period  of  time,  and  the  time  period  has 
elapsed.  The  output  for  this  type  of  casualty  first  lists  the  time  into  the  simulation  at  which  this 
casualty  occurred.  Next,  the  asset  group  identification  number  is  reported,  followed  by  the 
total  number  of  resulting  casualties  for  this  asset  group.  The  finai  entries  for  this  type  of 
casualty  are  the  accumulated  dose  (in  rads)  and  the  elapsed  time  (in  minutes).  In 
Example  26a,  It  is  shown  that  at  time  105.0  min  into  the  simulation,  0.48  members  of  Asset 
Group  46  accumulated  a  lethal  dose  of  3,232.85  rads,  which  was  received  15  min  earlier. 

Immediate  casualties,  shown  in  Example  26b,  is  another  type  of  casualty  that  is  reported 
in  a  nuclear  scenario.  An  immediate  nuclear  casualty  results  when  a  person  receives 
8,000  rads  or  more.  The  output  for  this  type  of  casualty  reports  the  time  at  which  the  casualty 
was  assessed,  the  identification  number  of  the  affected  asset  group,  and  the  total  number  of 
casualties  assessed  that  asset  group.  Each  line  of  output  for  immediate  casualties  ends  with 
the  statement,  "OVER  8,000.  rads."  The  value  "8,000"  is  an  AURA  default  which  can  be 
altered  by  using  the  MAX  DOSE  command  which  is  an  optional  DOSE  PARAMETERS 
command.  For  further  information  regarding  the  use  of  these  commands,  the  user  is  referred 
to  the  AURA  input  manual  (Klopcic,  Sheroke,  and  Price  1990). 

Another  casualty-producing  nuclear  effect  occurs  when  an  asset  is  suffering  from  the 
effects  of  early  transient  incapacitation  (ETI).  The  resulting  output  for  this  type  of  casualty  is 
illustrated  in  Example  26c.  ETI  occurs  when  an  individual  receives  enough  radiation  to  induce 
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Example  26.  Casualties  •  Nuc  2. 


a  coma  for  a  period  of  time.  During  this  time,  the  victim  cannot  function  and  is  not  available 
to  the  unit.  ETi  episodes  are  reported  at  each  reconstitution  time.  The  first  value  reported  is 
the  time  into  the  simulation  at  which  the  episode  occurred.  The  identification  number  of  the 
affected  asset  group  along  with  the  total  number  of  members  of  that  asset  group  unconscious 
due  to  ETI  are  the  remaining  data  provided  by  this  output. 

The  CASUALTIES, ON  option  also  produces  a  report  of  expenditures  as  they  occur 
throughout  the  simulation.  This  output  applies  to  assets  that  are  expendable  by  time  and  not 
to  assets  which  are  expendable  by  repair  completion.  For  further  information  on  expendables, 
the  user  is  referred  to  the  AURA  input  manual  (Kiopcic,  Sheroke,  and  Price  1990).  The 
expenditure  report  gives  the  number  of  assets  removed  from  the  pool  of  available  assets  for 
the  given  asset  group.  The  first  entry  for  the  expenditure  output  is  the  time  at  which  the  asset 
was  expended.  Next,  the  total  number  of  assets  expended  and  the  group  identification 
number  are  reported.  This  output  is  illustrated  in  Example  27a. 

When  modeling  HEAT  STRESS,  the  CASUALTIES.ON  option  will  also  report  heat  stress 
casualties.  Heat  stress  casualties  are  personnel  assets  which  are  suffering  from  the  effects  of 
heat  stress.  The  user  is  referred  to  the  SAIC  report  on  heat  stress  for  a  comprehensive 
description  of  an  analysis  using  AURA’s  heat  stress  methodology  (McNally,  Stark,  Ellzy  1990). 
This  output,  illustrated  in  Example  27b,  provides  the  following  information:  the  number  of 
assets  (in  the  affected  asset  group)  that  are  experiencing  heat  stress,  the  asset  group 
identification  number,  target  point  location,  link  identification  number,  as  well  as  the  core 
temperature  and  citical  temperature  of  the  asset.  For  instance,  as  reported  in  Example  27b, 
at  a  time  of  5.0  min  prior  to  the  scenario,  9.55  elements  from  asset  group  No.  23  of  link 
No.  23,  located  at  target  point  18  had  core  temperahjres  of  38.5®  C  (101.3®  F)  and  critical 
temperatures  of  40.6®  C  (105.1®  F).  Heat  stroke  normally  occurs  when  the  internal  core 
temperature  of  the  human  body  exceeds  41.1®  C  (106®  F).  In  AURA,  personnel  suffering  from 
heat  stroke  are  considered  lethalities.  (For  further  information  on  the  calculation  of  core  and 
critical  temperatures,  see  AURA  Heat  Stress  report  [Kiopcic  1989].) 

The  use  of  the  RELIABILITY  OF  WEAPONS  command  in  conjunction  with  the 
CASUALTIES,ON  option  causes  a  report  of  reliability  failures  to  be  printed.  This  output  lists 
the  number  of  failures,  identification  number,  and  target  point  location  for  the  asset  group. 
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(All  scenarios  -  expenditures) 


64 


Example  27.  Casualties  -  Miscellaneous. 


Also  reported  is  the  type  of  failure  (i.e.,  light,  medium,  or  dead)  and  the  time  of  failure.  In 
Example  27c,  0.77  units  from  asset  group  No.  20,  located  at  target  point  No.  27,  had  a  light 
reliability  failure  at  180.0  min  into  the  simuiation. 

2.3.3  Depioyment  Dump  Tabie.  Example  28  shows  the  output  produced  when  the 
DEPDMP,  ON  command  has  been  specified  as  an  output  option  in  the  input  runstream.  This 
table  reports  the  exact  location  of  each  asset  in  terms  of  which  target  point  (TGTPNT)  and 
job/iink  (JTGTLK)  the  asset  resides  in  at  the  time  specified.  Reported  for  every  target  point  is 
the  target  point  number,  the  number  of  the  link  at  that  target  point,  the  asset  group 
identification  number,  and  the  number  of  people  in  the  asset  group.  The  target  point  number, 
link  number,  and  asset  group  number  are  assigned  by  AURA  with  respect  to  the  input  order  of 
the  data,  in  Example  28,  at  a  time  of  5  min  into  the  scenario,  target  point  No.  1  contains 
job/iink  No.  28  which  is  performed  by  the  one  person  in  asset  group  No.  1 .  The  primary 
usage  of  this  table  is  to  provide  the  capability  to  monitor  the  dynamic  allocation/reallocation 
process  during  the  simulation. 

2.3.4  Dosage  Table.  The  Dosage  Table  reports  all  nuclear  or  toxic  dosages  as  received 
by  personnel  assets.  In  AURA,  dosages  are  accumulated  with  respect  to  target  point.  That 
is,  all  personnel  assets  at  each  target  point  receive  the  dosage  amount  received  by  the  target 
point.  The  Dosage  Table  consists  of  the  various  parameters  pertaining  to  the  dosage 
received  by  personnel  at  the  affected  target  point.  This  information  is  generated  by  the 
inclusion  of  the  output  option  DOSE,ON  in  the  input  runstream.  The  Dosage  Tables 
generated  for  chemical  and  nuclear  runs  differ  considerably;  therefore,  an  illustration  and 
explanation  is  provided  for  each  scenario.  Examples  29  and  30  illustrate  Dosage  Tables 
generated  for  chemical  and  nuclear  scenarios,  respectively. 

The  first  three  entries  in  the  chemical  Dosage  Table  are  the  time  (units  designated  by 
user,  in  this  case  seconds)  at  which  the  dosage  was  received,  the  number  of  personnel 
affected,  and  the  associated  target  point  number.  The  target  point  is  given  as  a  number 
which  when  cross-referenced  with  the  Deployment  Table  gives  the  coordinates  and  other  data 
specified  for  that  asset.  Following  the  target  point  is  the  entry  FGHM.  FGHM  identifies  the 
homelink  asset  identification  number  at  that  target  point.  The  next  entry  reports  the  MOPP  for 
each  asset  group  at  the  time  the  dosage  was  received.  The  MOPP  may  be  either  ORIG 
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**♦  DEELOYMENT  AT  TIME***  5.0  TGTEW  JTGTLK  ASSET(  NUMBER ) 


1 

28 

1(1.00) 

2 

70 

53(1.00) 

3 

29 

2(1.00) 

5 

1 

3(1.00) 

114 

39 

23(1.00) 

115 

40 

29(1.00) 

WHERE: 

TGTPNT  is  the  number  of  the  target  point  (assigned  by  AURA) 
JTGILK  is  the  number  of  the  link  at  TGTPNT  ( assigned  by  AURA  ) 

I 

ASSET  is  the  number  of  the  asset  group  (assigned  by  AURA) 
NUMBER  is  the  number  of  assets  in  the  asset  group 


Example  28.  Deployment  Dump  Table. 


66 


DOSAGE  TABLE 
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Example  29.  Dosage  Table  (Chem). 
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Example  30.  Dosage  Table  (Nuc). 


(original)  or  ALT  (alternate).  The  dosage  type  is  the  next  entry  in  the  table  and  may  be  either 
a  "PRC  LIQ"  (percutaneous  liquid)  or  "TOX  VPR"  (vapor)  chemical  agent.  Finally,  the 
cumulative  total  dosage  received  (up  to  the  current  time  period  of  interest)  by  each  target 
point  is  reported. 

The  Nuclear  Dosage  Table  (Example  30)  first  lists  the  number  of  personnel  within  the 
asset  group  receiving  nuclear  dosage.  Next,  the  identification  number  corresponding  to  that 
asset  group  is  given.  The  asset  identification  number  can  be  cross-referenced  with  the  Asset 
Table  to  determine  the  name  of  the  asset  as  well  as  other  information  related  to  the  asset. 
Following  this  information  is  the  posture  and  nuclear  kill  criteria.  The  nuclear  posture  is  a 
code  number  which  describes  the  protective  posture  of  personnel.  In  AURA,  codes  No.  1,  2, 
and  3  are  reserved  for  the  postures,  "in  the  OPEN,"  "in  the  OPEN-BUT-THERMALLY- 
SHIELDED,"  and  "in  a  FOXHOLE,"  respectively.  Codes  No.  4-16  may  be  specified  by  the 
user  and  can  be  used  to  indicate  such  postures  as  "in  a  TANK,"  "in  an  APC,"  etc.  The 
nuclear  posture  code  rissigned  is  related  to  the  amount  of  shielding  the  user  affords  personnel 
within  the  asset  group,  in  Example  30,  all  assets  listed  in  the  table  have  nuclear  posture  1  (in 
the  OPEN),  which  means  no  shielding  from  the  nuclear  blast.  The  deployment  coordinates  for 
the  affected  assets  are  reported  following  the  posture  entry.  Next,  the  nuclear  dosage 
(specified  in  rads)  received  at  the  specified  target  point  is  reported.  The  last  entry  in  the  table 
is  the  neutron-to-gamma  ratio,  associated  with  the  shielding  input. 

2.3.5  DUMPS.  Example  31a  depicts  a  sample  of  the  data  generated  by  the  inclusion  of 
the  DUMPS,  ON  output  option  in  the  AURA  input  runstream.  During  the  AURA  optimization 
process,  the  Asset  Allocation  Algorithm,  simulating  the  commander’s  resource  allocation 
decisions,  reports  the  status  of  the  allocation  process  at  each  reconstitution  time  designated  in 
the  input  runstream.  Usage  of  the  DUMPS  option  provides  a  consolidated  unit  status  report 
for  each  replication  and  enables  the  user  to  track  the  criteria  inherent  to  the  dynamic  asset 
allocation  process.  These  criteria  are  reported  on  FORTRAN  unit  No.  S  in  the  general  format 
described  below  in  the  following  text. 

Reported  first  is  the  output  header  label.  This  is  the  same  information  as  produced  at  the 
top  of  the  standard  output  (FORTRAN  unit  No.  6)  and  senres  to  identify  the  time  and  optional 
comments  for  the  AURA  run.  Next,  the  random  number  seeds  inherent  to  the  replication  are 
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DUMPS  OUTPUT 

ENCOUNTER  NUMBER  1 
AURA  RUN 

ASPIB  AMMUNITION  SUPPLY  POINT  IN  MOPPO 
RUN  ID  #  05/  15/91  09:56:27 

*«««****««  »  *  «  *  «  *  *  ****  **  **  *****  *  *** 

(((  RANDOM  NUMBER  SEEDS  AT  START  =  64310.  58218.  16804.  ))) 

REHJCATION  1  RX  SEEDS  =  64310.  58218.  16804. 

TIM=  0.0,  EFF=  1.0000.  SCH=  1.  WKLS= — 

TIM=  15.0,  EFF  =  02500.  SCH=  1.  WKLS=  -5 

TIM=  30.0,  EFF=02500.  SCH=  1,  WKLS=  -5 

WHERE: _ 

HM  is  the  time  (in  minutes)  of  the  reconstitution 
EFF  is  the  unit  effectiveness  value  at  dme  TIM. 

SCH  is  the  number  of  the  chain  that  is  under  consideration 
WKLS  is  the  number  of  the  weak  link  that  is  limiting  effectiveness 


(a) 

DUMP9  OUTPUT 

AURA  RUN 

ASPIB  AMMUNITION  SUPPLY  POINT 
RUN  ID#  05/15/91  09:56:51 

1  3  1  0.896E+02  0.121E+04  ■f).697E402  0.697E+02  MLRS 

-1  -1  -1  osxxm-iW  O.OOOE400  aoooE+oo  0.000E400 

48 


1 

1 

600.000 

2292.168 

1619270 

0.000 

2505.000 

1772.000 

0.000 

1 

1 

600.000 

2231.815 

1673.686 

0.000 

2525.000 

1772.000 

0.000 

1 

1 

600.000 

2310285 

1645.686 

0.000 

2545.000 

1772.000 

0.000 

1 

1 

600.000 

2311.853 

1620.809 

0.000 

2565.000 

1772.000 

0.000 

1 

1 

600.000 

2258.334 

1590.789 

0.000 

2585.000 

1771000 

0.000 

1 

1 

600.000 

2456.451 

1635.880 

0.000 

2725.000 

1771000 

0.000 

(b) 


Example  31.  DumoS  and  DumoQ  Outputs. 
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output.  Finally,  at  each  reconstitution  time,  the  unit  effectiveness,  the  number  of  the  subchain 
that  is  limiting  performance,  and  the  weak  link  within  ttie  subchain  is  reported.  In 
Example  31a,  at  the  time  15.0  min  into  the  mission,  the  unit  was  at  25%  effectiveness,  and 
subchain  No.  1  contained  the  weak  link,  which  was  link  No.  5.  A  minus  sign  preceding  the 
link  number  indicates  that  the  link  has  been  limited  by  the  number  of  assets  allowed  to 
perform  in  the  link. 

2.3.6  DUMP9.  Example  31b  shows  a  sample  of  the  data  generated  by  the  DUMP9,  ON 
output  option.  This  data  is  written  to  FORTRAN  output  unit  No.  9  and  reports  the  incoming 
weapon  parameters,  including  weapon  identification  descriptors  (as  assigned  by  AURA), 
designated  aim  points,  and  actual  burst  points.  The  amount  and  type  of  information  written  to 
unit  No.  9  is  dependent  upon  the  scenario  type  modeled.  Example  31b  depicts  the 
information  reported  for  a  chemical  scenario.  The  following  sections  will  reference  the 
information  provided  for  a  conventional  and  nuclear  scenario. 

Reported  initially  is  the  output  header  label.  This  information  serves  to  identify  the  time 
and  optional  comments  for  the  AURA  run.  The  first  line  of  data  in  Example  31b  depicts  a 
chemical  scenario  and  reports  the  weapon  number,  weapon  type,  lethality  code,  weapon 
range  parameters,  and  the  weapon  name.  The  weapon  number  is  sequentially  assigned  by 
AURA  with  respect  to  the  order  that  the  weapons  were  input.  A  value  of  999  as  the  weapon 
number  indicates  a  nuclear  scenario.  The  weapon  type,  shown  as  3  in  this  example,  is  the 
code  used  by  AURA  to  differentiate  which  scenario  is  being  modeled.  In  AURA,  weapon 
types  are  coded  1 ,  2.  and  3  and  represent  a  conventional,  nuclear,  and  chemical  scenario, 
respectively.  The  lethality  code  for  a  chemical  scenario  translates  to  the  chemical  agent 
modeled.  In  a  chemical  scenario,  codes  1 ,  2,  3,  and  4  correspond  to  ’G’,  ’V’,  ’H’,  and  T’ 
agents,  respectively.  For  a  nuclear  and  conventional  scenario,  a  non-zero  lethality  code 
number  simply  indicates  that  there  is  a  lethality  data  file  from  which  to  access  the  necessary 
lethality  data.  Next,  the  Cartesian  coordinates  representing  the  range  of  weapon  effects  are 
reported.  In  a  nuclear  scenario,  these  values  are  immeasurable,  and  AURA  simply  reports  a 
meaningless  value  of  1 .0  for  all  range  directions.  In  a  conventional  scenario,  the  maximum 
X-Y  coordinates  realized  for  the  weapon  effects  are  reported.  In  a  chemical  scenario,  as 
shown  in  Example  31b,  the  crosswind  and  downwind  coordinates  of  the  chemical  cloud 
pattern  are  reported.  The  final  piece  of  data  reported  in  the  first  line  is  the  alphanumeric 
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weapon  name.  In  this  case,  the  Multiple  Launch  Rocket  System  (MLRS)  is  being  modeled. 
The  second  line  of  data  in  Example  31b  is  used  to  indicate  the  end  of  weapon  data  and  is 
represented  by  values  of  -1  for  the  weapon  data  and  0.0  for  the  coordinates. 

The  next  section  of  the  DUMPS  Table  reports  ttie  criteria  inherent  to  each  individual 
weapon  round  in  the  scenario.  This  section  begins  with  the  value  of  the  total  number  of 
rounds  in  the  scenario.  In  this  case,  the  number  of  rounds  totaled  48  by  virtue  of  the  fact  that 
there  were  4  MLRS  volleys  (each  volley  contains  12  rounds).  The  remaining  data  in  the  unit 
No.  9  file  are  the  targeting  parameters  for  each  round  employed  in  the  scenario.  Reported  for 
each  round  are  the  replication  number,  weapon  number,  time  of  detonation,  and  the 
associated  burst  point  and  aim  point  coordinates.  In  Example  31b,  the  first  round  shown 
occurred  at  600.0  min  into  the  first  replication  from  weapon  No.  1 .  The  actual  burst  point  for 
this  round  were  (2,292.17,  1 ,619.27)  with  a  height  of  burst  of  0.0  m.  The  designated  aim 
points  for  this  round  were  (2,505.00,  1 ,772.00).  It  should  be  noted  that  the  X  coordinates  (of 
the  aim  points)  for  the  remaining  rounds  increase  by  20  m/round.  This  information  can  be 
used  to  verify  the  targeting  methodology  used  for  the  scenario. 

2.3.7  Asset  Restedness.  Example  32a  illustrates  the  Asset  Restedness  Table  produced 
as  a  result  of  specifying  the  output  option  FATIGUE.ON.  This  table  is  printed  for  each 
reconstitution  and  provides  the  user  with  a  listing  of  the  amount  of  SLUNITs  used,  or  gained, 
as  well  as  the  current  sleep  deprivation  status  for  each  personnel  asset.  Recall,  a  SLUNIT  is 
defined  by  AURA  as  1  minute  of  effective  rest.  I  herefore,  to  say  that  an  asset  has 
480.0  SLUNITs  means  that  the  asset  has  received  8  hours  of  rest.  A  detailed  description  of 
the  AURA  sleep  deprivation  model  is  the  subject  of  chapter  4.3  of  Volume  1  (Sheroke  et  al. 
1990b). 

The  first  line  reports  the  time  at  which  the  asset’s  sleep  deprivation  Is  updated  and  is 
shown  by  the  header  "SLUNIT  (RESTEDNES^v  UPDATE  AT  TIME  1440.0."  The  subsequent 
lines  list,  by  asset  number,  the  number  of  SLUNITs  gained,  used,  and  the  current  total  for  that 
asset.  For  instance,  in  Example  32a,  asset  No.  16  gained  0.00  SLUNITs  and  used  220.0 
SLUNITs,  which  implies  that  this  asset  was  working  during  the  time  period  of  interest.  The 
current  total  SLUNITs  for  this  asset  is  1,300.0.  The  remainder  of  the  assets  shown  in 
Example  32a  depict  the  AURA  default  of  1,520.00  SLUNITs  as  the  SLUNIT  total. 
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2.3.8  Assets  Resting.  The  Assets  Resting  Tsdbie  illustrated  in  Example  32b,  begins  with 
the  iine,  "ASSETS  RESTING  DURING  THE  NEXT  TIME  INTERVAL"  This  is  the  second  table 
resulting  from  the  output  option  FATIGUE, ON.  The  table  lists,  for  each  asset  group,  the 
number  of  members  for  that  asset  group  that  are  resting  at  the  given  time.  Also  included  is 
the  current  or  total  SLUNITs  for  each  member  of  the  listed  group.  In  the  first  line  of 
Example  32b  it  is  shown  that  12.00  members  of  the  asset  group  No.  86,  have  been  resting 
since  time  1 ,240.0  (minutes),  and  that  each  of  the  assets  of  this  group  now  have  a  total  of 
2.5  SLUNITs. 

2.3.9  Optimize.  Example  33  reports  the  information  printed  when  the  OPTIMIZE,  ON 
option  has  been  specified  within  the  output  section  of  the  input  runstream.  This  information 
provides  a  complete  printout  of  the  "decisions"  being  made  by  the  AURA  commander  model 
(the  AURA  asset  allocation  algorithm)  in  its  attempt  to  maximize  unit  effectiveness.  The 
AURA  asset  allocation  algorithm  (AAAA)  models  the  dynamic  process  of  battlefield  decision 
making  by  the  unit  commander  in  the  effort  to  utilize  the  best  available  assets  for  each 
mission  task  with  the  goal  of  "optimizing"  the  unit’s  ability  to  perform  a  specified  mission.  The 
means  of  solution  in  this  process  can  be  viewed  in  the  same  manner  as  any  optimal  path 
problem.  That  is,  the  AURA  commander  model  will  try  every  possible  combination  of 
assets-to-jobs  and  choose  the  combination  that  produces  the  maximum  unit  effectiveness 
value.  An  important  part  of  the  optimization  process  is  the  ability  to  model  the  phenomena  of 
decision-making  utilizing  recursive  memory  storage  techniques.  The  AAAA  is  capable  of 
modeling  the  recursive  nature  Inherent  to  the  optimization  process.  For  example,  the  optimal 
path  decision-making  process  may  lead  the  commander  to  assign  assets  for  several  levels  of 
unit  taskings.  The  commander  must  then  "remember"  the  current  optimal  path  while 
transversing  the  remaining  possibilities,  if  the  optimal  path  can  be  further  optimized  beyond  a 
given  level,  the  commander  must  "recall”  back  to  the  level  of  similarity  and  store  the  updated 
optimal  path.  In  AURA,  the  process  of  transversing  backwards  in  a  recursive  manner  is 
termed  a  "walkback."  When  the  OPTIMIZE,  ON  option  Is  specified,  every  node  in  the 
transversal  of  the  AURA  optimization  subroutines  encountered  during  the  simulation  is 
reported.  The  AURA  optimization  subroutines  are  OPTMIZ,  CPLOPT,  ORLOPT,  SBCOPT, 
CRWOPT,  and  LNKOPT  and  are  responsible  for  the  optimization  of  chains,  compound  links, 
orlinks,  subchains,  crews,  and  links,  respectively.  Example  33  illustrates  the  optimization 
walkback  process. 
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The  walkback  process  begins  upon  commencement  of  the  scenario  as  shown  in  the  first 
line  of  Example  33.  Reported  next  is  a  listing  of  the  chain  segment  numbers  in  the  order  of 
most  fragile  (least  effective)  to  the  strongest.  In  AURA,  segment  fragility  is  measured  by  the 
number  of  effective  assets  which  can  serve  in  the  segment.  That  is,  the  lower  the  number  of 
effective  assets  available  to  a  segment  the  more  fragile  the  segment.  In  Example  33,  Chain  1 
contains  seven  segment  numbers  each  followed  (in  parentheses)  by  the  number  of  assets 
required  in  the  segment.  Segment  No.  7  Is  shown  to  have  CPL/ORL  in  lieu  cf  an  integer 
value  for  the  number  of  assets.  In  this  case,  AURA  assumes  that  since  segment  No.  7  is 
comprised  of  either  a  compound  link  (CPL)  or  an  orlink  (ORL),  the  fragility  of  this  segment  is 
small  and  therefore  listed  last  in  the  segment  list.  This  assumption  can  seemingly  be  flawed  if 
the  number  of  assets  in  the  compound  link/orlink  is  less  than  that  of  the  previously  listed 
segments.  However,  the  thoroughness  of  the  AURA  optimization  process  will  alleviate  this 
discrepancy  at  a  later  reporting  time.  The  remainder  of  the  optimization  walkback  report 
depicts  the  dynamic  process  followed  by  the  AURA  asset  allocation  algorithm.  For  every 
subroutine  encountered  in  the  traversal,  the  walkback  reports  the  string  "WALKBK:"  followed 
by  the  traversal  direction,  optimization  subroutine  name,  number  of  the  weakest  segment,  and 
the  unit  effectiveness  for  the  current  path.  The  traversal  direction  can  be  viewed  in  two  ways: 
the  direction  of  the  overall  path  and  the  subroutine  reporting  location.  From  the  overall  path 
perspective,  the  string  "PRE"  refers  to  the  downward  path  taken  through  the  optimization 
subroutines  while  "POST"  refers  to  an  upward  path.  Additionally,  the  strings  "PRE"  and 
"POST"  represent  the  beginning  and  ending  reporting  location  within  the  optimization 
subroutine.  To  further  explain  this  subject,  the  AURA  optimization  subroutines  are  structured 
in  a  hierarchical  method  in  the  same  manner  as  the  AURA  functional  structures.  The 
hierarchy  from  top  to  bottom  for  functional  structures  (with  corresponding  subroutines)  are  as 
follows:  chains  (OPTMIZ),  compound  links  (CPLOPT),  orlinks  (ORLOPT),  subchains 
(SBCOPT),  crews  (CRWOPT),  and  links  (LNKOPT).  Therefore,  to  say  that  a  traversal  is  in 
the  downward  direction  means  that  the  path  taken  is  in  the  top-to-bottom  direction. 

AURA’S  commander  model  is  based  upon  the  premise  of  optimizing  the  links  (or  jobs)  in 
the  unit.  Subroutine  LNKOPT  contains  the  methodology  for  the  assessment,  reassignment, 
and  allocation  of  assets  within  these  links.  During  the  optimization  walkback  process,  each 
pass  through  subroutine  LNKOPT  produces  a  status  report  of  the  link  currently  being 
optimized.  The  information  reported  includes  the  following;  the  numbers  of  the  functional 
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structures  containing  the  link  undergoing  optimization,  the  link  identification  number,  the 
number  of  assets  currently  assigned  in  the  link,  effectiveness  of  substitute  to  be  used  in  link, 
degradation  due  to  fatigue  on  this  link,  degradation  due  to  wearing  MOPP  ensemble,  total 
degradation,  effective  degradation  of  available  substitute,  number  of  effective  assets  currently 
assigned  in  link,  total  number  of  assets  assigned  to  link,  and  the  current  link  effectiveness. 

The  functional  group  numbers  are  reported  in  sequence,  representing  the  chain  segment,  the 
compound  link  part,  the  orlink  branch,  the  subchain  element,  the  crew,  and  the  link.  In 
Example  33,  the  first  pass  through  subroutine  LNKOPT  produced  the  line:  WALKBK:  4  0  0 
0  0  7  ID,  AVL,  etc.  This  is  interpreted  as  link  No.  7  in  chain  segment  No.  4  is  being 
degraded  by  asset  group  No.  46  which  contains  0.50  assets.  The  zeros  indicate  that  link 
No.  7  is  not  a  part  of  a  higher  order  structure.  Furthermore,  the  following  facts  can  be 
derived: 

•  The  substitute  available  to  replace  the  most  degraded  asset  can  perform  the  job  at  100% 
effectiveness; 

•  The  asset  may  be  degraded  by  fatigue  and  MOPP  if  applicable  (a  value  of  "1 "  indicates 
the  asset  will  be  subjected  to  100%  of  the  degradation  effects): 

•  The  asset  may  be  degraded  a  maximum  of  100%; 

•  There  are  currently  0.50  assets  assigned  to  this  link  in  which  a  maximum  of  0.50  assets 
required; 

•  And,  the  resultant  link  effectiveness  based  upon  the  aforementioned  criteria  is  2%. 

Also  provided  within  the  traversal  process  are  informative  notations  indicating  important 
conclusions  drawn  from  the  optimization  process.  For  example,  the  strings  "TRYING 
SECOND  LEVEL  SUBSTITUTION"  or  "FAILED  TO  IMPROVE  LINK"  may  appear  within  the 
traversal  indicating  the  optimization  status.  It  should  be  noted  that  all  informative  messages 
emanate  from  the  link  optimization  subroutine  LNKOPT,  which  is  the  algorithm  responsible  for 
all  asset  reallocation  actions.  The  complete  list  of  possible  notations  which  may  appear  in  the 
optimization  walkback  report  and  their  descriptions  follow. 

EFF.  OF  LINK  JXYZ  =  IS  >  GOAL  OF 


-  This  message  which,  if  spelled  out,  reads  "Effectiveness  of 
link/job  at  target  point  (JXYZ)  is  greater  than  the  goal 
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effectiveness  for  this  link"  and  is  used  to  report  an 
improvement  for  the  current  link.  The  goal  effectiveness  of 
each  link  is  set  to  1%  greater  than  the  effectiveness  value 
of  the  link  being  optimized.  Therefore,  this  diagnostic 
simply  means  that  at  the  current  reporting  time  the  commander, 
via  reallocation  decisions,  improved  the  effective  capability 
of  the  iink/job  at  target  point  (JXYZ)  by  at  least  1%. 

INSUF.  CAP.  :  ID.  MOPP,  DS-TM,  FAT.  TDG 

-  "INSUFFICIENT  CAPABILITY."  This  diagnostic  Indicates  that 
the  current  asset  under  consideration  is  not  capable  of 
improving  the  link.  The  asset  identification  number  (ID) 

is  reported  as  well  as  the  degradation^  criteria  (described 
above)  corrupting  the  asset’s  capability. 

TRYING  SECOND  LEVEL  SUBSTITUTION 

-  This  diagnostic  indicates  that  the  "commander"  has  been 
forced  to  try  a  "second  best"  substitute  for  the  current 
link  under  consideration. 

SUCCEEDED:  BKFLLED  XXX  OF  ID  YYY,  REPLACING  ID  ZZZ  IN  LINK  XYZ 

-  The  "commander"  has  successfully  Improved  the  effectiveness 
of  the  current  link  under  consideration.  Read  as  "backfilled 
the  number  of  available  assets  (XXX)  of  asset  group  ID  (YYY), 
replacing  asset  ID  number  (ZZZ)  in  link  number  (XYZ)."  This 
means  that  the  commander  was  able  to  improve  the  effective 
link  capability  by  substituting  asset  (ZZZ)  as  a  replacement 
for  asset  (YYY)  in  link  XYZ. 
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INSUFFICIENT  PROGRESS  IN  OPTIMIZING  LINK _ ,  DETECTED  IN  LNKOPT 

•  The  effectiveness  of  the  current  link  under  consideration 
has  yet  to  be  improved  (at  this  reporting  time). 

*  FAILED  TO  IMPROVE  * 

( ANY  ASSIGNMENTS  INTO  THIS  LNK/CRW/SBC  NOT  MADE  ) 

-  "Commander"  cannot  improve  the  effective  capability  of 
the  current  iink,  crew,  or  subchain  under  consideration. 

**  WARNING-22  **  AT  LEAST  ONE  LINK  OPTIMIZATION  TERMINATED  BECAUSE 
ADDITION  OF  (POSSIBLY  DEGRADED)  ASSETS  RESULTED  IN 
INSUFFICIENT  IMPROVEMENT.  DETAILS  WRITTEN  ON  FILE 
8  IF  DUMP8  OPTION  IS  ON. 

-  Self  explanatory.  See  DUMP8  file  description. 

2.3.10  Particular  Assets.  The  PARTICULAR  ASSETS  option  serves  as  an  output  control 
tool  by  allowing  the  user  to  restrict  the  assets  to  be  included  in  casualty  reports,  dosages, 
contamination  reports,  etc.  For  instance,  if  PARTICULAR  ASSETS,  CRANE  OPER,  SERVC 
PERS  is  specified  in  the  input  runstream,  this  would  restrict  all  entries,  in  outputs  listed 
previously,  to  include  only  the  assets,  CRANE  OPER  and  SERV  PERS. 

2.3.1 1  Posture.  Example  34  reports  the  battlefield  posture  of  unit  personnel.  This  table  is 
useful  to  the  analyst  in  determining  which  assets  have  undergone  a  change  in  protective 
posture  and  the  time  that  the  posture  change  occurred.  This  table  is  generated  only  when  the 
output  option  POSTURE,ON  is  specified  in  the  input  runstream. 

There  are  four  types  of  posture  changes  whi(^  can  be  reported  in  this  table.  For  this 
example,  a  change  to  "INVULN.  MOPP"  was  resultant  of  the  scenario  modeled  and  caused 
asset  No.  46  to  change  from  its  original  MOPP  to  MOPP4  at  time  1,080.0  minutes.  In  AURA, 
MOPP4  is  considered  to  be  the  default  invulnerable  MOPP.  The  other  possible  posture  for 
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AT  TIME  10880.0,  TGT  PT  8  (ASSET ID  =  88)  WENT  TO  INVULN.  MOPP  PSTR. 


this  chemical  scenario  exampie  would  be  "ALT.  MOPP,"  which  means  that  the  asset  changed 
to  a  predefined  MOPP  different  from  the  one  initially  assigned.  The  DEPLOYMENT  and 
REST  input  commands  described  in  the  AURA  Input  Manual  (Klopcic,  Sheroke,  and  Price 
1 990)  are  examples  of  two  possible  methods  by  which  to  specify  an  alternate  MOPP.  When 
modeling  a  conventional  or  a  nuclear  scenario,  there  are  two  types  of  protective  postures  that 
will  be  output  in  this  table.  These  postures,  defined  in  the  same  manner  as  those  typical  of  a 
chemical  scenario,  are  as  follows:  "WENT  TO  ALT.  CONV/NUC"  and  "WENT  TO  INVULN. 
CONV/NUC." 

2.3.12  Random  Number  Seeds.  Example  35  illustrates  the  output  of  the  random  number 
seed  values  used  at  the  beginning  of  and  throughout  the  AURA  execution.  The  primary 
usage  of  the  RANDOM  NUMBER, ON  output  option  is  to  provide  the  capability  to  report  the 
random  numbers  drawn  and  used  for  each  replication.  Random  numbers  are  used  frequently 
within  AURA  to  statistically  sensitize  data  such  as  weapon  delivery  errors,  personnel 
vulnerability  to  nuclear/chemical  dosages,  and  general  statistical  methods  inherent  to 
simulation  modeling.  AURA  contains  a  default  set  of  random  number  seeds  which  are  used  to 
initiate  the  random  number  generation  process.  (See  subroutine  DEFALT  in  Volume  2  for 
AURA  defaults)  (Sheroke  et  al.  1990a).  The  SEED  input  command  permits  the  user  to  define 
a  customized  set  of  random  number  seeds  to  be  used  for  the  following  phenomena  modeled 
in  AURA;  WEAPON,  FAILURE,  and  HEAT  STRESS.  The  methodology  of  these  phenomena 
is  described  in  Volume  1  of  the  AURA  Programmer/Analyst  Guide,  and  the  SEED  command  is 
described  in  the  AURA  Input  Manual  (Sheroxe  et  al.  1990b;  Klopcic,  Sheroke,  and  Price 
1990). 

2.3.13  Reconstitution.  The  RECONSTITUTION  output  command  causes  an  asset  status 
report  after  every  reconstitution  event.  The  parameters  available  with  the  RECONSTITUTION 
command  are  PARTIAL,  ON,  and  ONCE  and  are  described  below.  The  RECONSTITUTION 
command  also  provides  the  capability  to  restrict  the  reconstitution  results  produced  to  a 
specific  time  interval  within  the  simulation.  The  AURA  Input  Manual  (Klopcic,  Sheroke,  and 
Price  1 990)  provides  the  spectrum  of  options  and  parameters  for  use  with  the 
RECONSTITUTION  command. 
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RANDOM  NUMBER  SEEDS 

(((RANDOM NUMBER  SEEDS  AT  START  ^63410.  58218.  16804.  93359.  7398.))) 

(((RANDOM  NUMBER  SEEDS  AT  END  =  86134137.  1661488710.  16804.  93359.  7398.))) 

Example  35.  Random  Number  Seeds. 
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Usage  of  the  RECONSTITUTION.  PARTIAL  output  option  results  In  the  table  shown  in 
Example  36.  The  information  reported  in  this  teible  is  described  for  every  reconstitution  time 
and  includes  the  current  status  of  such  data  as  the  following:  equipment  contamination,  unit 
effectiveness,  jobs/links  engaged  in  mission,  and  the  analysis  of  the  links  which  may  be 
degrading  the  unit. 

Reconstitution  number  2,  shown  second  in  Example  36,  provides  the  entire  spectrum  of 
information  produced  by  the  RECONSTITUTION,  PARTIAL  command.  The  first  datum 
reported  is  the  time  of  the  reconstitution  event.  In  this  case,  the  unit  reconstituted  at  a  time  of 
1 0,995.0  min  into  the  scenario.  Next,  the  contaminated  equipment  status  is  reported.  The 
modeling  of  contaminated  equipment  is  optional  in  AURA  and  can  be  controlled  via  the 
CONTAMINATED  USAGE  command  in  the  input  runstream.  The  CONTAMINATED  USAGE 
command  allows  the  user  to  specify  the  assets  (equipment)  which  may  still  be  used  for  the 
mission  even  though  they  are  contaminated  as  a  result  of  a  chemical  attack.  This  table 
reports  the  asset  identification  number(s)  of  any  assets  which  have  been  designated  as 
contaminated  usable.  If  no  assets  have  been  designed  contaminated  usable,  the  word 
"NONE"  is  reported  as  shown  in  Example  36.  Reported  next  is  the  number  of  the  operant 
chain,  its  effectiveness,  and,  if  applicable,  the  weakest  (most  degraded)  segment  of  the  chain. 
In  this  example,  at  time  10,995.0  min,  chain  number  1  is  operating  at  25%  and  is  being  most 
degraded  by  the  third  chain  segment.  The  complete  list  of  link  numbers  used  in  the  mission  is 
shown  next.  This  information  serves  primarily  as  a  reference  tool  to  verify  which  links  are 
being  used  at  this  time  period. 

The  final  section  of  data  presented  is  the  weak  links  analysis.  The  identification  number  of 
the  job  which  is  most  degrading  (i.e.,  the  weak  link)  and  the  reason  for  degradation  are  printed 
here.  The  effectiveness  value  of  this  weak  link  is  reported  as  well  as  the  effectiveness  of  the 
mission  segment  impacted  by  the  weak  link.  The  reason  for  degradation  is  explicitly  shown  in 
this  example  as  being  "LINK  5  HAS  NO  ITEMS  ALLOCATED."  One  can  then  conclude  that 
the  assets  required  to  perform  link  number  5  have  either  become  casualties  or  are  being 
used  as  replacements  in  other  jobs  more  critical  to  mission  accomplishment.  In  this  case,  link 
number  5  degraded  the  unit  the  most  with  an  effectiveness  value  of  0%.  The  impact  of  the 
lack  of  effectiveness  in  job  number  5  resulted  in  an  effectiveness  value  of  15%  for  the  tasking 
represented  by  segment  number  3. 


RECONSTITUTION  NUMBER  I  AT  TIME 


Example  36.  Reconstitution  Table. 


If  the  RECONSTITUTION,  ON  option  is  specified,  the  results  produced  by  the 
RECONSTITUTION,  PARTIAL  (described  above)  are  reported  in  conjunction  with  a  complete 
matrix  of  the  current  assignments  of  assets  to  links.  Example  13  depicts  an  example  of  this 
matrix,  known  as  the  Link-Substitutability  matrix.  Recall,  from  the  Link  Status  Table 
(Example  13).  for  each  asset  type,  the  links  (or  jobs)  in  which  the  members  of  the  asset  type 
can  serve  are  shown.  The  letter  "H"  signifies  the  asset  deployed  is  a  "homelink."  A  homelink 
is  the  primary  job  of  the  asset  in  which  it  can  immediately  serve  with  100%  effectiveness.  An 
entry  of  the  form  time/effectiveness/order  indicates  a  job  into  which  an  asset  can  substitute  in 
the  time  amount  (minutes)  and  with  the  corresponding  effectiveness  value.  The  order  number 
indicates  the  sequence  in  which  the  user  specified  the  substitutes  and  is  used  to  choose  one 
particular  substitute  over  another  if  all  other  quantities  (namely,  versatility  and  effectiveness) 
are  equal.  Finally,  a  blank  entry  indicates  that  no  substitution  is  possible  for  the  link. 

If  the  RECONSTITUTION,  ONCE  option  has  been  designated,  all  information  output  by 
the  RECONSTITUTION,  ON  command  will  be  reported  for  the  initial  reconstitution  only. 

2.3.14  Table  of  Surviving  Assets.  Example  37  depicts  the  Table  of  Surviving  Assets, 
which  reports  the  surviving  assets  at  each  reconstitution  time.  This  table  is  generated  at  the 
end  of  every  replication  when  the  output  option  "REPLICATION,  ON"  is  specified  in  the  input 
runstream.  This  table  is  generally  used  as  a  tool  to  determine  the  specific  assets  which  were 
attrited  in  each  replication.  The  format  of  the  Table  of  Surviving  Assets  is  described  in  the 
following  paragraphs. 

Prior  to  reporting  the  surviving  asset  data,  the  number  of  the  current  replication  is  printed. 
The  column  headers  for  each  individual  asset  name,  with  its  corresponding  identification 
number,  are  printed  below  the  table  header.  In  this  example,  only  the  surviving  assets  within 
the  first  25  asset  types  are  shown.  The  column  header  "TIME"  represents  the  user- 
specified  internal  reconstitution  times  of  interest.  In  Example  37,  0.0,  1 5.0,  and  30.0  have 
been  specified  as  reconstitution  times  for  the  unit  under  study.  The  initial  time  reported  refers 
to  the  commencement  of  the  simulation  and  generally  corresponds  to  the  time  of  attack.  The 
time  of  attack  used  in  this  example  is  0.0  min.  The  number  of  survivors  reported  for  each 
asset  group  at  time  0.0  min  into  the  simulation  is  equivalent  to  the  initial  available  assets  for 
each  asset  group.  The  Table  of  Surviving  Assets  reports  the  status  of  every  asset  available 
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REPLICATION  NUMBER  1 
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to  the  unit.  When  the  number  of  surviving  assets  is  initially  equal  to  0.0,  this  corresponds  to  a 
DUMMYLINK.  Recall,  a  dummylink  is  defined  as  a  job  which  has  no  asset  of  the  same  name. 
DUMMYLINKS  are  links  which  have  no  particular  assets  assigned  to  them  but  are  filled,  when 
needed,  by  substitutes.  For  further  information  on  DUMMYLINKS,  the  analyst  is  referred  to 
the  AURA  Input  Manual  (Klopcic,  Sheroke,  and  Price  1990).  For  this  reason,  the  number  of 
survivors  will  remain  0.0  unless  the  job  is  performed.  In  this  example,  the  first  two  assets 
listed  in  the  table,  "FIREMEN"  and  "FIRETEAM,"  are  dummylinks  and  have  0.00  listed  as  the 
number  of  survivors. 

Finally,  the  replication  table  reports  the  amount  of  computer  CPU  time  required  for  the 
replication.  This  information  can  be  used  by  the  programmer/analyst  to  trace  the  computer 
time  requirements  of  each  replication. 

2.3.15  Timer  Output  Table.  The  data  reported  in  Example  38  represent  the  computer 
time  at  specified  times  of  interest  during  the  simulation.  The  primary  use  of  these  data  is  to 
provide  the  AURA  programmer/analyst  with  a  method  to  diagnose  larger  than  expected  time 
requirements  during  the  simulation.  The  TIMER,ON  option  causes  the  Timer  Output  Table  to 
report  the  computer  time  at  the  beginning  and  end  of  each  of  the  AURA  events.  This  allows 
the  user  a  means  to  measure  the  computer  time  required  by  portions  of  an  AURA  execution. 

The  Timer  Output  Table  consists  of  outputs  in  the  form  "%%TIMER%%  BEGINNING 
EVENT  1 .  CPUTIM=  4.634."  This  simply  states  that  the  first  event  began  at  the  time 
4.634  seconds  into  the  AURA  execution.  The  successive  time  reports  indicate  the  amount  of 
time  before  the  next  event  begins.  With  this  information,  the  user  can  subtract  from  the 
previous  time  to  determine  the  time  it  took  to  complete  the  previous  event.  This  is  useful  to 
detect  problem  areas  that  may  occur  during  the  AURA  run.  Frequently,  this  information  is 
used  to  see  which  replication  took  the  most  time  to  complete  or  where  the  code  halted  the 
execution  process. 

2.3.16  Weapon  Table.  The  Weapon  Table  reports  the  targeting  parameters  associated 
with  each  round  employed  for  all  replications.  This  table  is  commonly  used  by  the  analyst  to 
determine  the  actual  ground  zero  coordinates  of  the  weapon  round  with  respect  to  the 
designated  aim  points.  The  information  in  this  table  can  assist  the  analyst  with  the 
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TIMER  OUTPUT 

%%TIMER%%  BEGINNING  EVENT  1.  CPUTIM= 
%%TIMEk%%  BEGINNING  EVENT  2.  CPUTIM= 
%%TIMER%%  BEGINNING  EVENT  3.  CPUTIM= 
%%TIMER%%  BEGINNING  EVENT  4.  CPUTIM= 
%%TIMER%%  BEGINNING  EVENT  5.  CPUTIM* 
%%TIMER%%  BEGINNING  EVENT  6.  CPUTIM= 
%%TIMER%%  BEGINNING  EVENT  7.  CPUTIM= 


Example  38.  Timer  Output  Table. 


4.634 

4.691 

4.731 

4.760 

4.788 

4.818 

5.109 
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interpretation  of  the  levei  of  damage  incurred  by  the  unit.  Note  that  a  large  target  or  delivery 
error  may  also  contribute  to  an  unexpected  low  level  of  damage  in  a  given  replication.  For 
example,  the  analyst  may  intuitively  correlate  a  high/low  degree  of  precision  in  weapon 
accuracy  due  to  an  increased/decreased  amount  of  casualties  and  damage.  The  analyst  will 
quite  often  utilize  this  rationale  to  explain  changes  in  unit  casualties  in  the  study.  A  typical 
Weapon  Table  is  illustrated  in  Example  39. 

The  first  line  of  the  Weapon  Table  contains  the  time  period  of  this  weapon  report  as  well 
as  the  status  of  target  acquisition.  In  this  example,  the  weapon  table  reports  "AT  TIME  0., 
TARGET  ACQUISITION  SUCCEEDED."  which  means  that  the  target  was  successfully 
acquired  at  the  start  of  the  simulation.  The  next  line  provides  the  initial  target  location  error 
(TLE)  and  the  actual  target  location  error  calculated  by  AURA.  This  information  is  given  in  the 
statement  "INITIAL  TLE(RANGE,DEFL)  =  S  iO.O,  30.0  ACTUAL  TLE  =  (316.0,  30.0)."  The 
actual  TLE  is  calculated  by  normalizing  the  initial  TLE  by  a  random  number  multiplier.  Only 
in  the  case  where  the  initial  TLE  is  (60.0,  -60.0)  will  the  initial  TLE  and  actual  TLE  be  the 
same. 

The  remainder  of  the  Weapon  Table  reports  the  weapon  arrival  parameters  including  the 
following:  weapon  type,  time  of  detonation,  intended  aim  point,  and  actual  burst  point.  The 
string  "EMPL#  (VOLL#)  1  ( 1 ),"  represents  the  weapon  employment  number  (EMPL#)  and  the 
volley  number  (VOLL#).  These  two  values  will  be  the  same  when  the  VOLLEY  command  is 
used  alone.  If  the  ROUND  command  is  used,  no  volley  number  will  be  printed.  The  weapon 
number  is  reported  as  the  next  string.  In  AURA,  weapons  are  sequentially  numbered  in  the 
order  in  which  they  are  specified  in  the  input  runstream.  In  this  example,  weapon  No.  1 
detonated  at  time  10,980.0.  The  statement  "DGZ  =  (  2505.0, 1772.0,  0.0  )"  represents  the 
intended  aim  point  coordinates  in  the  three-dimensional  Cartesian  system.  The  final  part  of 
the  line  is  "AGZ  =  (2292.2,  1 61 9.2,  0.0)"  which  represents  the  actual  ground-zero  (AGZ)  or 
actual  burst  point.  The  offset  realized  in  the  actual  ground-zero  coordinates  (with  respect  to 
the  intended  aim  point)  is  a  result  of  the  effect  of  target  location  and  delivery  errors. 
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AT  TIME  0..  TARGET  ACQUISITION  SUCCEEDED 
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Example  39.  Weapon  Table. 


2.4  Final  -  Averaged  Results. 


2.4.1  Repeat  of  Warnings.  This  section  provides  a  consolidated  list  of  the  informative 
warnings  which  occurred  in  the  AURA  run.  The  warning  diagnostics  produced  by  AURA  are 
informative  messages  indicating  a  logical  disagreement  or  syntactical  error  in  AURA  and  do 
not  affect  the  successful  completion  of  the  AURA  run.  The  appendix  provides  a  numerical 
listing  of  ail  AURA  warning  diagnostics  including  the  recommended  solution  to  resolve  cause 
of  warning,  reference  to  appropriate  command  format  in  input  manual,  and  the  subroutine 
name  from  which  the  warning  diagnostic  originated. 

2.4.2  Effectiveness  vs.  Time  Table.  Example  40  depicts  the  AURA  Effectiveness  vs. 

Time  Table.  This  table  reports  the  unit  effectiveness  status  at  every  reconstitution  time  during 
the  simulation  and  includes  a  frequency  distribution  of  effectiveness  values  over  all 
replications.  For  each  reconstitution  time,  the  following  information  is  reported;  the  time 

(in  minutes)  of  the  reconstitution  event,  the  average  unit  effectiveness  value  over  all 
replications,  the  operant  chain  number,  and  ttie  frequency  distribution  of  the  unit  effectiveness 
value.  For  example,  at  the  time  of  5  min  into  this  simulation,  the  effective  capability  of  this 
unit  to  perform  the  mission  (designated  by  operant  chain  No.  1)  is  58%.  At  the  next  reporting 
time,  120.0  min,  the  unit  is  shown  to  have  improved  to  a  rate  of  90%,  a  rate  at  which  the  unit 
continues  to  operate  for  the  remainder  of  the  simulation.  Generally,  the  unit  is  shown  to  be 
most  degraded  during  (or  shortly  after)  an  attack,  as  is  the  case  with  Example  40  at  the 
5.0  min  point.  At  the  reporting  times  shown  after  the  attack,  the  effectiveness  of  the  unit 
recovers  to  90%  due  to  the  commander’s  reallocation  of  available  surviving  assets. 

2.4.3  Table  of  Sun/iving  Assets.  The  T£i)le  of  Sunriving  Assets  reports  the  number  of 
surviving  assets  in  each  asset  group  at  each  reconstitution  time.  (The  user  is  referred  to 
Example  37  for  the  illustration  of  this  table.)  Included  in  the  survivor  totals  are  those  assets 
which  have  been  contaminated  by  a  chemical  or  nuclear  dose.  The  data  shown  in  this  table 
provide  the  AURA  analyst  with  a  dynamic  view  of  the  status  of  each  asset  group  throughout 
the  scenario.  Each  column  of  the  Table  of  Surviving  Assets  describes  a  unique  asset  group. 
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Example  40.  Effectiveness  vs.  Time  Table. 


The  column  header  lists  the  asset  name  and  group  identification  number.  The  number  of 
surviving  assets  within  each  asset  group  is  reported  with  respect  to  each  reconstitution  time. 
All  reconstitution  times  considered  in  the  modeling  scenario  are  listed  in  the  first  column  of  the 
table.  This  table  is  also  described  in  the  intermediate  results  section  of  this  report. 

2.4.4  Cumulative  Summary  of  Heat  Stress  Casualties.  The  Cumulative  Summary  of  Heat 
Stress  Casualties  Table  (illustrated  in  Example  41)  is  produced  when  the  individual  task  input, 
HEAT  STRESS,  is  included  in  the  input  runstream.  The  table  lists  the  cumulative  number  of 
heat  stress  casualties  at  the  specified  internal  reconstihJtion  times.  For  further  information  on 
heat  stress,  the  user  is  referred  to  the  AURA  input  manual  (Klopcic,  Sheroke,  and  Price  1990). 

2.4.5  Survivor  Summary  Table.  Example  42  illustrates  the  Survivor  Summary  Table.  This 
table  reports  the  total  number  of  surviving  assets  (personnel  and  equipment)  available  to  the 
unit  at  each  reconstitution  time.  The  Survivor  Summary  Table  provides  an  at-end  summation 
of  the  unit  survivors  vs.  time.  Unit  survivors  are  computed  as  an  average  over  ail  replications. 
Also  reported  is  two  times  the  standard  deviation  of  the  averaged  unit  survivors  at  each 
reconstitution  time.  This  table  is  generated  only  when  the  SUMMARY  (or  NUCLEAR 
SUMMARY)  output  command  has  been  specified  in  the  input  runstream  (see  the  AURA  Input 
Manual  [Klopcic,  Sheroke,  and  Price  1990]).  The  most  common  usage  of  the  SUMMARY 
command  is  in  conjunction  with  the  parameter,  PERSONNEL,  which  is  depicted  in 
Example  42.  Shown  in  this  example,  at  a  time  of  8  hr  (480.0  min),  there  was  an  average  of 
233.06  (of  the  original  237.0  deployed)  survivors  available  to  the  unit.  The  value  of  4.9  is 
computed  as  two  times  the  standard  deviation  realized  at  the  8-hr  reporting  time. 

2.4.6  Toxic  Dose  Table.  The  Toxic  Dose  Table,  illustrated  in  Example  43,  is  produced  for 
chemical  scenarios  only.  The  table  reports,  by  asset  group  number,  the  total  assets  contained 
in  each  dose  bin.  In  addition,  a  total  across  all  asset  groups  is  reported  for  each  bin.  This 
table  is  useful  for  monitoring  the  percent  of  unit  personnel  which  may  be  degraded  due  to 
sublethal  doses. 

The  table  header  Is  set  up  so  that  the  numbers  in  the  first  row  indicate  the  endpoints  of 
the  range  for  each  dose  bin.  The  second  row  of  numbers  lists  the  midpoint  value  for  each 
range.  Column  one  of  the  table  reports  the  asset  group  identification  number.  Columns  two 
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aji4ULATIVE  SUMMARY  OF  HEAT  STRESS  CASUALTIES 


TIME  HEAT  STRESS  CASUALTIES  (CUM) 


0.0 

0.00 

5.0 

12.95 

120.0 

24.56 

240.0 

35.33 

360.0 

43.54 

480.0 

48.64 

600.0 

51.49 

725.0 

54.12 

840.0 

55.94 

960.0 

56.86 

1005.0 

57.46 

1120.0 

57.88 

1240.0 

57.88 

1360.0 

57.88 

1480.0 

57.88 

1600.0 

57.88 

1725.0 

57.89 

Example  41 .  Cumulative  Summary  of  Heat  Stress  Casualties. 
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SURVIVOR  SUMMARY,  SELECTED  CATEGORIES,  WITH  S.  D. 

INCLUDES  SICK  BUT  FUNCTIONAL  PERSONNEL 

DOES  NOT  INCLUDE  CONTAMINATED  OR  DAMAGED  EQUIPMENT 

*  i|i  Ik  Ik  lit  4i  ik  4t  4t  4c  :|i  1(1 « Ik  lie  *  ik  It!  *  *  41  Ik  4c  41  1|<  *  *  4: 4i  i|E  i|>  i|t  It  41 1|>  41  <1  i|c  lit  lit  41  i|t  41  lie  lit  ^  III  i|c  4i  )|e  *  i|i  i|>  * 


TIME  PERSONNEL 


0.0  237.00  +/-  0.00 

480.0  233.06  +/-  4.90 

710.0  233.06  +/-  4.90 


NOTE:  +  /  -  IS  2  TIMES  THE  STANDARD  DEVIATION  OF  THE  MEAN 


Example  42.  Survivor  Summary  Table. 
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TOXIC  DOSE 


***  IV  DOSE,  NORMALIZED  TO  1  LETHAL  DOSE 


0.05  0.15  0.25  0.35  0.45  0.55  0.65  0.75  0.85  1.00 

V  VVVVVVVV  V  OVER 
ID  NEGUG  0.10  0.20  0.30  0.40  0.50  0.60  0.70  0.80  0.93  5.50  10.00 


1 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

2 

0.85 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

3 

0.89 

0.00 

0.00 

0.11 

0.12 

0.14 

0.41 

0.48 

0.32 

0.49 

0.83 

0.00 

4 

1.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

5 

023 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

6 

027 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

7 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

8 

0.60 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

9 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

10 

1.14 

0.00 

0.00 

0.02 

0.09 

0.14 

0.23 

0.24 

0.27 

0.22 

024 

0.00 

11 

0.13 

0.00 

0.01 

0.00 

0.00 

0.00 

0.03 

0.00 

0.05 

0.04 

0.04 

0.00 

12 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

13 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

14 

0.01 

0.00 

0.00 

0.00 

0.00 

0.08 

0.18 

0.28 

0.09 

0.31 

0.08 

0.00 

TOTAL 

5.12 

0.00 

0.01 

0.13 

0.21 

0.36 

0.85 

1.00 

0.73 

1.06 

1.19 

0.00 

*»*4i***««4i«»****«««4>4i«**««**********»**********4i*******»********«»*«»*»*4i  *********** 


Example  43.  Toxic  Dose  Tgyble. 
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through  th‘  .^en  report  the  number  of  assets  contained  in  each  dose  bin.  The  second  column 
lists  the  number  of  assets  receiving  negligible  (NEGLIG)  doses.  A  negligible  dose  is  any  dose 
that  is  less  than  0.05  of  the  normalized  dose.  The  next  column,  headed  by  "0.10,"  contains 
assets  that  have  received  doses  >  0.05  and  <  0.15  normalized  doses.  Note  that  "0.10"  is  the 
midpoint  of  the  range  for  this  dose  bin.  The  remainder  of  the  columns  are  s^.t  up  in  this 
manner  with  the  last  column  containing  the  number  of  assets  that  have  received  doses 
^  10.00  normalized  doses.  In  Example  43,  under  the  column  headed  by  "0.5,"  it  is  shown  that 
0.14  assets  from  group  3,  0.14  assets  from  group  10,  and  0.08  assets  from  group  14  received 
doses  in  the  range  of  >  45%  (0.45)  to  <  55%  (0.55)  of  one  lethal  dose.  In  the  last  line  of  the 
table,  the  total  personnel  for  all  asset  groups  in  the  bin  with  the  midpoint  of  0.5  (normalized 
doses)  is  0.36,  which  is  simply  the  sum  of  the  previously  listed  values. 

The  midpoint  values  listed  in  Example  43  are  AURA  default  values.  These  values  may  be 
changed  under  the  mnemonic  DOSE  PARAMETERS  in  the  input  runstream.  For  more 
information,  the  analyst  is  referred  to  the  AURA  input  manual  (Klopcic,  Sheroke,  and  Price 
1990). 

2.4.7  Nuclear  Dose  and  Casualties  Table.  The  Nuclear  Dose  and  Casualties  Table, 
illustrated  in  Example  44,  is  similar  to  the  Toxic  Dose  Table  (Example  43).  It  reports  for  each 
asset  group  number,  the  total  number  of  assets  receiving  nuclear  dosages.  In  addition,  the 
Nuclear  Dose  and  Casualties  Table  also  reports  the  totals  for  immediate,  dose-time,  blast,  and 
thermal  casualties  for  each  asset  group. 

The  dosage  portion  of  the  table  is  set  up  in  the  same  manner  as  the  Toxic  Dose  Table 
with  the  first  row  of  the  header  containing  the  endpoints  of  the  range  for  each  dosage  bin  and 
the  second  row  containing  the  midpoint  of  each  range.  The  values  in  the  header  of  the 
nuclear  dose  table  refer  to  the  number  of  rads  (cGy)  received  by  the  asset.  The  midpoint 
values  listed  in  the  header  of  Example  44  are  AURA  default  values.  These  values  can  also 
be  changed  under  the  DOSE  PARAMETERS  mnemonic.  (See  the  AURA  input  manual 
[Klopcic,  Sheroke,  and  Price  1990].) 
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NUCLEAR  DOSE  AND  CASUALTIES 
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The  casualty  portion  of  the  Nuclear  Dose  and  Casualties  Table  lists,  for  each  asset  group, 
the  total  number  of  casualties  for  each  of  the  following  casualty  types:  immediate,  dose-time, 
blast,  and  thermal.  An  immediate  casualty  results  when  a  personnel  asset  receives  over 
8,000  rads.  This  value  is  an  AURA  default  but  may  be  changed  under  the  MAX  DOSE 
mnemonic.  A  dose-time  casualty  occurs  when  an  individual  receives  sufficient  nuclear  dosage 
over  time  to  kill  that  asset.  Blast  and/or  thermal  casualties  are  a  result  of  an  asset  receiving 
sufficient  blast  and  thermal  effects  to  produce  a  lethality.  The  effect  of  blast  is  measured  in 
psi^/sec,  while  thermal  effects  are  measured  in  cal/cm^.  The  probability  of  kill  (PK)  for  blast 
and  thermal  is  calculated  in  the  subroutine,  NUCDMG.  (For  more  information,  see  Volume  1 
of  the  AURA  Programmer/Analyst  Guide  [Sheroke  et  al.  1990b].)  A  more  detailed  report  of 
nuclear  casualties  can  be  generated  by  the  use  of  the  CASUALTIES, ON  output  option  (see 
Casualties,  Intermediate  Results  section.) 

As  in  the  case  of  the  Toxic  Dose  Table,  the  Nuclear  Dose  and  Casualties  Table 
summarizes  the  cumulative  totals  for  each  dose  bin  and  casualty  type. 

2.4.8  Thermal  and  Blast  Degradation  Status  Table.  Thermal  Degradation  Status  and 
Blast  Degradation  Status  are  two  tables  produced  when  the  NUCLEAR  SUMMARY.ON  option 
is  specified  within  the  input  runstream.  These  tables  are  illustrated  in  Examples  45a  and  45b, 
respectively. 

The  Thermal  Degradation  Status  Table  lists,  for  each  posture,  the  total  number  of 
personnel  assets  receiving  various  levels  of  thermal  fluence.  The  amount  of  thermal  fluence 
is  divided  into  ranges  as  listed  in  the  header  of  Example  45a.  The  first  column  lists  the 
nuclear  posture  code.  Codes  1-3  are  reserved  for  in-the-OPEN,  in-the-OPEN-BUT- 
THERMALLY-SHIELDED  and  in-a-FOXHOLE,  respectively.  The  remaining  postures  are  user- 
specifiable  postures.  The  headers  for  columns  two  through  eight  list  the  various  ranges  of 
thermal  fluence  for  the  nuclear  weapon.  Column  two  lists  the  number  of  assets  receiving  less 
than  9.3  cal/cm*.  The  third  column  lists  the  number  of  assets  receiving  thermal  fluence  in  the 
range  of  9.3  to  12.5  cal/cm^,  etc.  The  last  column  reports  the  total  number  of  assets  receiving 
amounts  of  thermal  fluence  greater  than  60.5  cal/cm^  As  an  example  of  how  to  read  this 
table,  the  total  number  of  assets  in  posture  1  (in  the  open)  receiving  thermal  fluence  in  the 
range  of  12.6  to  18.9  cal/cm^  is  159.00.  Note  that  thermal  environment  is  only  considered  for 
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Example  45.  Thermal  and  Blast  Degradation  Status  Tables. 


personnel  in  posture  1  (in  the  OPEN).  For  this  reason,  values  for  all  other  postures  in  the 
table  will  always  be  0.00. 

The  Blast  Degradation  Status  Table  is  similar  to  the  Thermal  Table,  except  that  the  bins 
contain  the  number  of  personnel  exposed  to  various  levels  of  blast  static  overpressure, 
reported  in  psi  (or  Ibs/in^).  (For  more  information,  the  user  is  referred  to  the  AURA  NUKESDO 
report  [Price  1991].)  The  nuclear  postures  are  the  same  for  this  table  as  for  the  thermal  table. 
The  first  bin  reports  the  number  of  personnel  exposed  to  5.0  to  9.6  psi.  Blast  effects  less  than 
5.0  psi  are  not  reported  because  these  values  are  considered  to  be  negligible.  The  highest 
bin  reported  is  for  overpressure  values  greater  than  100  psi.  In  Example  45b,  2.26  people  in 
posture  1  received  between  51.6  and  74.5  psi. 

2.4.9  ETI  Summary.  This  table  reports  the  total  number  of  man-weighted  early  transient 
incapacitation  (ETI)  episodes  that  occur  during  the  simulation.  The  term  "man-weighted" 
refers  to  the  number  of  personnel  (including  fractional  persons)  undergoing  an  ETI  episode  at 
each  reconstitution  time,  summed  over  all  reconstitution  times  and  averaged  over  all 
replications.  (A  person  can  have  more  than  one  ETI  episode  during  an  AURA  run.)  Output 
for  this  table  is  illustrated  in  Example  46. 

2.4.10  Dose-Degraded  Capability  and  Incapacitation  -  All  Personnel.  The  Dose-Degraded 
Capability  and  Incapacitation  -  All  Personnel  Table,  illustrated  in  Example  47,  reports  the 
percentage  of  personnel  assets  in  each  effectiveness  category  and  the  average  effectiveness 
for  all  personnel  at  each  internal  reconstitution  time.  The  categories  are  specified  as  ranges 
of  effective  capability  values.  For  example,  an  asset  who  is  operating  at  67%  effectiveness  at 
a  time  of  2  hr  (120.0  min)  into  the  mission  would  fall  into  the  60-70  percentile  range. 

The  Dose-Degraded  Capability  and  Incapacitation  -  All  Personnel  Table  produced  by  a 
chemical  run  lists  only  the  percentage  of  personnel  contained  in  each  effectiveness  category 
and  the  average  effectiveness  for  the  unit.  For  a  nuclear  scenario,  this  table  also  includes 
entries  listing  the  number  of  assets  experiencing  ETI  and  permanent  complete  incapacitation 
(PCI)  episodes  for  each  replication.  These  entries  appear  as  the  two  right-most  columns  in 
the  table  following  the  average  effectiveness  data.  Example  47  illustrates  this  difference 
between  the  two  scenarios. 
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NO.  OF  (  MAN -WEIGHTED)  EPISODES  =  42.95 


Example  46.  ETI  Summary. 
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2.4.11  Contaminated  Asset  Survivors  Table.  Example  48  depicts  the  Contaminated  Asset 
Survivors  Table.  This  table  reports  the  number  of  contaminated  assets  in  each  asset  group 
averaged  over  all  replications.  In  AURA,  an  asset  may  become  contaminated  if  exposed  to  a 
chemical  agent  or  nuclear  warhead.  The  user  is  referred  to  Volume  1  of  the  AURA 
Programmer/Analyst  Guide  for  a  detailed  discussion  of  the  modeling  of  contaminated  assets  in 
AURA  (Sheroke  et  al.  1990b).  The  number  of  contaminated  assets  in  each  asset  group  is 
reported  at  each  reconstitution  time.  As  shown  in  Example  48,  at  8  hr  (480.0  min)  into  the 
simulation,  2.00  FRKLFT6C  (asset  identification  No.  7)  became  contaminated.  Note, 
personnel  assets  are  not  considered  contaminated:  therefore,  the  number  of  contaminated 
personnel  will  always  be  zero.  For  personnel  casualty  estimates,  see  Section  2.3.2  of  this 
report. 

2.4.12  Link  Results  vs.  Time  Table.  The  Link  Results  Table,  shown  in  Example  49, 
reports  the  final  status  of  all  links  at  each  reconstitution  time.  For  each  link,  the  following 
information  is  provided:  the  number  of  times  the  link  was  employed  in  the  mission,  the 
number  of  times  the  link  was  weak  due  to  asset  unavailability,  the  number  of  times  the  link 
was  weak  due  to  the  limitation  of  the  assets  permitted  to  serve  in  the  link,  the  number  of  times 
the  link  was  used  in  a  compound  link,  the  number  of  times  the  link  was  used  in  an 
as-available  repair  status,  and  the  number  of  times  the  link  was  the  most  limiting  in  the 
as-available  status.  This  information  is  commonly  used  by  the  analyst  to  determine  the  role  of 
each  task  toward  the  success  or  failure  of  the  mission.  The  AURA  link  allocation/availability 
methodology  is  described  in  detail  in  Volume  1  (Chapter  4.1)  of  the  AURA  Programmer/ 
Analyst  Guide  (Sheroke  et  al.  1990b).  As  shown  in  the  example,  the  link  name,  link  number, 
and  associated  values  are  listed  in  the  columns,  and  the  reconstitution  times  are  reported  in 
the  rows.  For  example,  at  120.0  min,  the  DRIVER/RTO  (link  No.  2)  task,  was  used  in  all  100 
replications  and  was  weak  due  to  asset  unavailability  in  six  of  the  replications. 

2.4.13  Compound  Link  Parts  vs.  Time  Table.  Example  50  illustrates  the  Compound  Link 
Parts  vs.  Time  Table.  This  table  provides  a  reference  to  the  effective  capability  of  the 
compound  link  parts  at  each  reconstitution  time  in  the  scenario.  In  Example  50,  the 
compound  link  is  comprised  of  10  compound  link  parts.  Recall,  the  compound  link  is  used  to 
represent  a  task  which  is  the  aggregation  of  several  subtasks,  each  of  which  is  "weighted" 
with  respect  to  the  contribution  of  this  subtask  towards  the  primary  task.  As  shown  in 
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Example  48.  Contaminated  Asset  Survivors  Table. 


LINK  RESULTS  VS.  TIME  FOR  REPLICATION 
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Example  49.  Link  Results  vs.  Time  Table. 


AVERAGE  EFFECTIVENESS  USED .  OVER  ALL  REPLICATIONS 

(  NOTE :  EF  CPL  NOT  WEAK.  MORE  CAPABILITY  MAY  HAVE  BEEN  AVAILABLE  THAN  WAS  USED 
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Example  50.  the  Compound  Link  Parts  vs.  Time  Table  reports  the  effectiveness  value 
(percentage)  for  each  compound  link  part.  In  tfiis  example,  throughout  all  reporting  times, 
compound  link  part  No.  1  began  at  95%  effective  and  ended  at  83%  effective,  while 
compound  link  part  No.  6  remained  at  100%  effective  throughout  this  mission.  If  another  link 
exists  other  than  the  compound  link,  the  compound  link  may  only  be  optimized  until  it  is  no 
longer  the  weak  link.  Therefore,  the  values  in  this  table  may  not  reflect  the  full  capability  of 
the  compound  link. 

2.4.14  Segment  Results:  Cumulative  Times  Weakest  vs.  Time  Table.  In  AURA,  the 
chain  construct  is  used  to  represent  all  of  the  tasks  required  to  perform  a  mission.  Each  of 
these  tasks  (or  subtasks)  are  referred  to  as  segments  of  the  chain.  A  segment  may  be 
comprised  of  any  construct  (or  combinations  of  constructs)  which  are  used  to  represent  lower 
echelon  taskings  of  the  mission  (such  as  links,  orlinks,  etc.).  Example  51  illustrates  the 
Segment  Results  Table.  The  Segment  Results  Table  reports  the  segment  type  which  most 
degrades  the  unit  as  well  as  the  number  of  times  this  segment  is  the  "weak  link"  during  the 
optimization  process.  In  Example  51 ,  it  is  shown  that  chain  No.  1  is  comprised  of  five 
segments.  The  third  line  reports  the  construct  numbers  which  comprise  the  segment.  In  this 
case,  the  first  segment  is  link  No.  4,  the  second  segment  is  link  No.  6,  the  third  segment  is 
link  No.  7,  the  fourth  segment  is  comprised  of  subchain  No.  1  (denoted  by  the  preceding  "*" 
sign),  and  segment  No.  5  is  compound  link  No.  1.  Furthermore,  it  is  shown  that  segment 
No.  5  was  the  weakest  segment  in  all  20  optimization  attempts  for  this  mission. 

2.4.15  Chain  Results  vs.  Time  Table.  Example  52  reports  the  status  of  all  chains  at  each 
reconstitution  time  throughout  the  mission.  AURA  provides  the  capability  to  specify  multiple 
methods  to  perform  a  mission,  each  of  which  may  be  represented  as  a  chain.  The  Chain 
Results  vs.  Time  Table  lists  a  status  report  of  all  chains  used  in  the  scenario  by  providing 
such  information  as  the  following:  the  average  effectiveness  (over  all  replications),  the 
number  of  times  the  chain  was  the  strongest,  and  the  average  effectiveness  value  when  the 
chain  was  the  strongest.  In  AURA,  the  strongest  chain  refers  to  the  method  of  mission 
accomplishment  with  the  highest  effective  capability.  For  example,  suppose  there  are  two 
possible  methods  defined  to  perform  a  mission.  Method  1  (chain  No.  1)  and  Method  2  (chain 
No.  2).  At  any  given  reporting  time,  the  method  producing  the  greater  effective  capability  will 
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SEGMENT  RESULTS  :  CUMULATIVE  TIMES  WEAKEST  VS.  TIME 


CHAIN  #! 

1 

1 

1  . 

1 

1 

SEGMENT  #! 

1 

■  2 

.  3  . 

4 

5 

TIME  \  TYPE  ! 

4 

■  6 

.  7  . 

*1 

.  !1 

240.0 

!  0 

0 

0 

0 

20 

300.0 

!  0 

0 

0 

0 

20 

360.0 

!  0 

0 

0 

0 

20 

420.0 

!  0 

0 

0 

0 

20 

480.0 

!  0 

0 

0 

0 

20 

540.0 

!  0 

0 

0 

0 

20 

Example  51 .  Segment  Results  vs.  Time  Table. 
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CHAIN  RESULTS  VS.  TIME 


AVERAGE  EFFECTIVENESS 

NO.  OF  TIMES  CHAIN  IS  STRONGEST 

(  AVERAGE  EFFECTIVENESS  WHEN  STRONGEST  ) 

CHAINS 

TIME  I 


OjO  .  0.97 

20 

.  (0.97) 


240.0  •  0.92 

20 

.  (0.92) 


300.0  .  0.92 

20 

.  (0.92) 


360.0  .  0.93 

20 

.  (0.93) 


420.0  .  0.93 

20 

.  (0.93) 


480.0  .  0.93 

20 

.  (0.93) 


540.0  .  0.93 

.  20 
.  (0.93) 


Example  52.  Chain  Results  vs.  Time  Table. 
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be  the  strongest  chain.  In  Example  52,  only  one  chain  was  used,  resulting  in  the  effective 
capability  of  the  chain  to  be  reported  at  each  reconstitution  time.  (Had  a  second  chain  been 
modeled,  similar  information  for  the  chain  would  have  appeared  in  a  column  adjacent  to  chain 
No.  1 .)  As  shown  in  this  example,  this  chain  began  at  97%  and  degraded  to  93%  effective  in 
accomplishing  the  mission  over  the  time  period  considered. 

2.4.16  Average  Repairs  on  Repairable  Items.  The  Average  Repairs  on  Repairable  Items 
Table  (illustrated  in  Example  53)  is  produced  only  when  modeling  repair.  This  table  reports 
the  number  of  ordered  (ORDERD)  and  completed  (DONE)  repairs  for  each  level  of  repair. 

The  term  "ordered"  refers  to  the  total  number  of  repairs  needed  and  includes  any  reorders  of 
discontinued  repairs.  In  AURA,  repairs  are  ordered  based  on  the  availability  of  assets. 

Levels  of  repair  include  decontamination  (level  0)  (chemical  only),  light  (level  1 ),  and  medium 
(level  2)  and  relate  to  the  level  of  damage  received  by  an  asset.  For  example,  a  lightly 
damaged  asset  requires  light  repair,  and  an  asset  that  receives  medium  damage  requires 
medium  repair.  A  heavily  damaged  asset  is  considered  unrepairable;  therefore,  heavy  repair 
is  not  included  as  an  entry  in  the  table.  It  should  be  noted  that  these  levels  of  repair  are  user- 
selected  and  relate  to  specific  amounts  of  damage  received  as  dictated  by  the  lethality  file 
(see  AURA  Input  Manual  and  Volume  1  for  further  information  on  the  AURA  REPAIR 
methodology  (Sheroke  et  al.  1990b;  Klopcic,  Sheroke,  and  Price  1990]). 

The  first  column  of  the  table  contains  the  asset  group  identification  number  and  name. 
Data  for  level  0  repairs  is  printed  in  the  second  and  third  columns  only  when  a  chemical  or  a 
combined  chemical/conventional  scenario  is  modeled.  For  conventional  and  nuclear 
scenarios,  there  will  be  no  entries  listed  in  the  table  for  level  0  repairs.  Example  53  is  taken 
from  a  conventional  run.  Consequently,  no  data  is  printed  for  level  0  repairs.  Level  1  repair 
data  are  listed  in  columns  four  and  five.  The  remaining  two  columns  contain  the  data  for 
Level  2  repairs.  In  Example  53,  asset  No.  94,  the  CRANE  247,  received  damaged  for  which 
0.00  light  repairs  have  been  ordered  and  0.05  repairs  have  been  completed. 

2.4.17  Repair/Oecdhtamination  Summary  Table.  The  Repair/Decontamination  Summary 
Table,  illustrated  in  Example  54,  reports  the  end  of  encounter  repair/decontamination  status  of 
equipment  assets.  For  each  equipment  asset  group,  the  following  information  is  reported:  the 
asset  group  identification  number,  asset  group  name,  initial  number  of  assets  deployed  in 
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AVAERAGE  REPAIRS  ON  REPAIRABLE  ITEMS 

,^**^mm****m*********************’¥*********’ii* 


DECON 


LITE 


MEDIUM 


ASSET 

ORI£RD 

DOSE  C»DERD 

DONE 

C«DERD 

DONE 

80  PORKB 

1.67 

0.50 

1.78 

1.53 

81  FORK  a 

3.00 

2.75 

0.00 

0.00 

82  FORK  247 

0.00 

0.00 

0.00 

0.00 

92  CRANE  B 

0.00 

0.00 

0.00 

0.00 

93  CRANE  Cl 

0.37 

0.00 

0.00 

0.00 

94  CRANE  247 

0.00 

0.05 

0.00 

0.00 

119  OVENS 

0.00 

0.00 

0.00 

0.00 

120  PUMPlOO 

1.00 

0.00 

0.00 

0.00 

122  WATER  TRLR 

0.00 

1.00 

0.00 

0.00 

123  MIXER 

0.00 

0.00 

0.00 

0.00 

124  FLOUR  SIFTER 

0.00 

0.00 

0.00 

0.00 

125  TRUCKS 

0.00 

0.00 

0.00 

0.00 

126TRUCK5L 

0.00 

0.00 

1.00 

0.00 

127  TRUCK5P 

2.94 

0.83 

0.00 

0.00 

132  FILTER/SEP 

0.00 

0.00 

0.00 

0.00 

134  PETRO  FORK 

0.00 

0.00 

0.00 

0.00 

Example  53.  Averaged  Repairs  on  Reoairables  Table. 
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REPAIR/DECONTAMINATION  SUMMARY 


ASSET 

INITIAL 

UNHARMED 

CONTAMD 

LIT  DAM 

MED  DA 

80  FUEL  TANK  • 

9.0 

6.00 

0.00 

2.00 

1.00 

81  FORK  Cl 

1.0 

0.00 

0.00 

0.00 

0.00 

82  FORK  247 

1.0 

0.00 

0.00 

0.00 

0.00 

86  gens  B 

1.0 

0.00 

0.00 

0.00 

0.00 

87  GENS  Cl 

1.0 

0.00 

0.00 

0.00 

0.00 

88  GENS  247 

1.0 

0.00 

0.00 

0.00 

0.00 

92  CRANE  B 

1.0 

0.00 

0.00 

0.00 

0.00 

93  CRANE  Cl 

1.0 

0.00 

0.00 

0.00 

0.00 

94  CRANE  247 

1.0 

0.00 

0.00 

0.00 

0.00 

no  BSTH3 

S.0 

s.oo 

0.00 

0.00 

0.00 

111  BKY30 

1.0 

1.00 

0.00 

0.00 

0.00 

Example  54.  Repair/Decontamination  Summary  Table. 
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asset  group,  number  of  unharmed  assets,  number  of  contaminated  assets,  number  of  assets 
receiving  light  damage,  and  the  number  of  assets  receiving  medium  damage.  In  AURA, 
equipment  damage  status  is  categorized  with  respect  to  the  level  of  repair  required.  In  this 
example,  the  end  of  encounter  status  of  asset  group  number  80  (FUEL  TANKS)  is  as  follows: 
There  were  9.0  fuel  tanks  initially  deployed  for  the  mission,  whereby  6.0  of  the  fuel  tanks  were 
unharmed  throughout  the  mission,  no  fuel  tanks  were  contaminated,  2.0  received  light 
damage,  and  1 .0  fuel  tank  incurred  medium  damage.  The  information  provided  by  the 
Repair/Decontamination  Table  enables  the  analyst  to  isolate  causes  of  unit  degradation  that 
are  primarily  related  to  equipment  functionality.  The  inoperability  or  contamination  of 
equipment,  as  reported  in  this  table,  can  also  be  used  to  measure  the  criticality  of  equipment 
to  the  mission  requirements. 

2.4.18  Summary  of  Targeting  Characteristics  Table.  Example  55  illustrates  the 
end-of-encounter  targeting  characteristics  for  each  munition  employed  in  the  scenario.  The 
targeting  parameters,  which  are  described  below,  are  averaged  over  all  replications.  For  each 
weapon,  the  following  data  are  presented:  the  weapon  number  (internally  assigned  by 
AURA),  the  total  number  of  rounds  fired,  the  average  aim  point  coordinates,  the  average  burst 
point  coordinates,  and  the  standard  deviation  from  the  average  burst  point.  The  primary  use 
of  this  table  is  to  verify  that  round  distribution  is  taking  place  as  intended. 

2.4.19  Fatigue  Output  -  Total  Accumulated.  The  Fatigue  Output  -  Total  Accumulated 
Table,  illustrated  in  Example  56,  provides  the  analyst  with  an  assessment  of  the  sleep 
deprivation  status  of  unit  personnel.  In  AURA,  sleep  deprivation  is  modeled  by  quantifying  the 
amount  of  efficient  rest  (in  terms  of  minutes)  a  person  requires  and  expends  in  performing 
their  job  in  the  mission.  The  unit  of  measure  used  for  sleep  deprivation  in  AURA  is  called  a 
sleep  unit  or  SLUNIT.  One  SLUNIT  =  1  min  of  efficient  rest.  This  table  reports  the  rate  that 
SLUNITs  are  expended  and  the  rate  that  SLUNITs  are  accumulated  while  personnel  are 
resting.  For  a  more  detailed  description  of  AURA’s  Sleep  Deprivation/Fatigue  Model,  the  user 
is  referred  to  Volume  1  of  the  AURA  Programmer/Analyst  Guide  (Sheroke  et  al.  1990b).  A 
description  of  the  information  provided  in  the  Fatigue  Output  -  Total  Accumulated  Table  is 
given  in  the  following  paragraph. 
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SUMMARY  OF  TARGETING  CHARACTERISTICS 

iti«***4i4ii|iiti4it|i4«ti**«*»******iti**<t«ti**«******4>«4>**4>4i 


WPN.  NO 


NO.  RNDS 


MEAN  DGZ  MEAN  AGZ 


MEAN  AGZ  SD. 


Example  55.  Summary  of  Targeting  Characterist'cs  Table. 
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The  Fatigue  Output  -  Total  Accumulated  Table  is  separated  into  halves  with  identical 
column  headers  for  each  half.  The  first  column,  headed  by  "ID,"  contains  the  asset 
identification  number.  Column  two  has  the  header  "WORK  (MAN-)  (MIN)"  and  reports  the 
number  of  minutes  worked  by  each  asset.  The  next  column  is  headed  by  "WORK  (MAN-) 
(SLUN)"  and  provides  the  rate  that  SLUNITs  are  expended  while  working.  Column  four 
reports  the  amount  of  rest,  in  minutes  ("REST  (MAN-)  (MIN)"),  taken  by  each  asset. 

Column  5,  headed  by  "REST  (MAN-)  (SLUN),"  reports  the  rate  at  which  SLUNITs  are 
accumulated  while  people  are  resting.  The  last  column  is  headed  by  "SLEND"  which 
translates  to  SLUNITs  at  END.  This  column  contains  the  "SLUNIT  balance"  for  each  asset  at 
the  termination  of  the  mission. 

2.5  Summary.  This  report  has  presented  the  outputs  and  error  diagnostics  generated  by 
the  Army  Unit  Resiliency  Analysis  (AURA)  computer  simulation  model.  Through  the  usage  of 
detailed  examples,  the  AURA  analyst  is  provided  a  comprehensive  interpretation  of  the  output 
formats,  controls,  and  values  which  may  result  from  an  AURA  run.  The  report  was  organized 
to  enable  the  analyst  to  peruse  the  AURA  tables  in  the  general  sequence  that  they  occur  in 
the  output. 

Beyond  the  scope  of  this  report  are  techniques  for  developing  descriptions  of  unit 
operations  and  strategies  for  input  preparations.  These  topics,  in  addition  to  modeling 
considerations,  will  be  addressed  in  Volume  3  of  the  AURA  Programmer/Analyst  Guide 
(Sheroke  et  al.,  to  be  published). 
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APPENDIX: 

WARNING  AND  ERROR  DIAGNOSTICS 


121 


This  appendix  describes  the  warnings  and  fatal  error  messages  which  may  occur  in  an 
AURA  run.  The  warning  diagnostics  produced  by  AURA  are  informative  messages  indicating 
a  logical  disagreement  or  syntactical  nonconformity  in  AURA  and  do  not  affect  the  successful 
completion  of  the  AURA  run.  List  No.  1  is  a  numerical  listing  of  all  AURA  warning  diagnostics 
Included  for  each  warning  and  error  diagnostic  described  in  this  appendix  is  the  following 
information: 

•  Recommended  soiution  to  resolve  cause  of  warning  or  error; 

•  Reference  to  appropriate  command  format  in  input  manual  (if  applicable); 

•  Subroutine  from  which  warning  diagnostic  occurred. 

The  error  diagonstics  produced  by  AURA  are  defined  as  those  errors  which  abruptly 
terminate  the  run.  The  error  diagnostics  generally  fall  into  the  following  two  categories: 
command  syntax  errors  and  logical  errors.  Command  syntax  errors  result  from  a  flaw  in  the 
usage  or  format  of  an  AURA  input  command.  Logical  errors  occur  as  a  result  of  incorrect  or 
inappropriate  modeling  techniques.  Each  error  diagnostic  produced  by  AURA  provides 
information  relating  to  the  reason(s)  of  the  error’s  occurrence.  List  No.  2  is  a  numerical  listing 
of  all  error  diagnostics  coupled  with  information  presented  in  the  same  format  described  for 
warning  messages. 


List  No.  1 


1)  “WARNING-1  “  CAN  ONLY  SUPPORT  50  SIMULTANEOUS  REPAIR  ACTIONS. 

REPAIR  INPUT  CHANGED. 

a)  AURA  will  only  use  the  first  50  repair  actions  declared. 

b)  Check  parameters  in  REPAIR  mnemonic  card. 

c)  See  subroutine  RPRIN. 

2)  “  WARNING-2  “  END  CARD  MISSING  AFTER _ 

a)  User  omitted  END  card  after  specified  data  set  in  runstream;  END  card  is  essential 
after  NAMES  data. 
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b)  See  appropriate  mnemonic  card. 

c)  See  AURA  Volume  I  and  II  for  appropriate  subroutine. 

3)  **  WARNING-3  **  ASSET  LIST  DOES  NOT  INCLUDE _ 

a)  Asset  name  found  has  not  been  declared  in  the  ASSET  section. 

b)  Asset  must  be  listed  under  ASSETS  heading  in  mnstream. 

c)  Check  parameters  in  NAMES  mnemonic  card. 

d)  See  subroutine  FINDFG. 

4)  **  WARNING-4  **  POSTURE  OR  KILL  CRITERIA  FOR  ID,  DIFFERS  BETWEEN 

DEPLOYMENT  PTS. 

a)  Same  asset  has  different  posture  or  kill  criteria  at  different  deployment  points. 

b)  Check  parameters  in  DEPLOYMENT  and  NAMES  mnemonic  cards. 

c)  See  subroutine  DEPCHK. 

5)  **  WARNING-5  **  NO  LETHALITY  DATA  WAS  READ  FOR  WEAPON  NUMBER _ 

a)  Check  runstream  and  appropriate  lethality  file  whether  toxic,  nuclear,  or  conventional 
to  verify  matching  weapon  names. 

b)  Check  runstream  to  ensure  that  the  appropriate  lethality  mnemonic  card  was  input, 
i.e.,  CONVENTIONAL  LETHALITY,  TOXIC  DISPERSION,  NUCLEAR 
VULNERABILITY. 

c)  Check  parameters  in  NAMES  and  WEAPON  mnemonic  cards. 

d)  See  subroutine  WEPCHK. 

6)  *•  WARNING-6  **  VOLLEY  MUST  CONTAIN  MORE  THAN  1  ROUND. 

a)  Use  ROUND  mnemonic  card  to  simulate  one  incoming  round. 

b)  Check  parameters  in  VOLLEY  mnemonic  card. 

c)  See  subroutine  VLLYIN. 
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7)  **  WARNING'7  **  PERSISTENCE  TIME  OF  TOXIC  WEAPON  DISPERSION  # _ IS 


LONGER  THAN  ENCOUNTER  TIME.  ONCE  INTO  MOPP, 
PERSONNEL  WILL  NOT  GET  OUT. 

a)  To  analyze  unit  effectiveness  after  personnel  return  to  original  MOPP,  include  a 
reconstitution  event  at  a  point  in  time  beyond  the  persistence  time  of  the  agent. 

b)  Check  parameters  in  PERSiSTENCE.  WEAPON.  MOPP.  and  RECONSTITUTION 
mnemonic  cards. 

c)  See  subroutine  CLDTIM. 

8)  **  WARNING-8  **  THE  PARTS  OF  COMPOUND  LINK  SUM  TO _ . 

a)  Change  the  weighting  of  each  task  so  that  they  sum  to  one. 

b)  Check  parameters  in  COMPOUND  LINKS  mnemonic  card. 

c)  See  subroutine  CPLKIN. 

9)  **  WARNING-9  **  CONTAMINATED  ITEM  USAGE  DOES  NOT  REQUIRE  ALL 

PERSONNEL  TO  BE  IN  MOPP. 

a)  The  CONTAMINATED  USAGE  card  has  been  used.  If  no  MOPP  safe  posture  has 
been  identified  in  the  runstream  (see  MOPP  ALL),  exposed  personnel  will  be  allowed 
to  continue  operations  with  contaminated  equipment.  This  may  not  be  realistic. 
Furthermore,  the  contact  hazard  of  using  contaminated  items  is  not  modeled. 
Chemical  casualties  may  be  underestimated. 

b)  Check  parameters  in  CONTAMINATED  USAGE,  MOPP,  and  DEPLOYMENT 
mnemonic  cards. 

c)  See  subroutine  DEPCHK. 

10)  *•  WARNING-10  *•  ONLY  ONE  STOCHASTIC  PK  IS  DRAWN  PER  TARGET  POINT 

ITEMS  AT  TGT  PT  WILL  BE  KILLED  AS  A  GROUP  NOT 
INDEPENDENTLY. 


125 


a)  Items  should  be  deployed  at  different  deployment  points  when  using  the  stochastic 
mode. 

b)  Check  parameters  in  MODE  and  DEPLOYMENT  mnemonic  cards. 

c)  See  subroutine  DEPCHK. 

11)  **  WARNING-11  **  CONTAMINATED  ITEMS  MAY  NEVER  BE  USED  SINCE 

PERSONNEL  TARGET  POINT  HAS  NO  MOPP-SAFE  POSTURE. 

a)  Modeling  an  unprotected  scenario  to  assess  casualities  without  MOPP-safe  posture 
while  permitting  use  of  contaminated  items  which  cannot  be  used  by  personnel  in  less 
than  MOPP4. 

b)  Unit  effectiveness  may  be  underestimated  since  personnel  cannot  use  contaminated 
items  to  perform  their  mission. 

c)  Check  parameters  in  CONTAMINATED  USAGE,  MOPP,  and  DEPLOYMENT 
mnemonic  cards. 

d)  See  subroutine  DEPCHK. 

12)  **  WARNING-12  **  HEAT  STRESS  PROBABILITY  =  0,  FOR  TOXIC  K.C. _ IN  MOPP 

.  EASY  JOB  OR  COLD  DAY? 


a)  Heat  stress  is  not  turned  on  or  parameters  set  too  low?  If  cold  day  or  easy  job.  heat 
stress  need  not  be  modeled. 

b)  Check  parameters  in  HEAT  STRESS  mnemonic  card. 

c)  See  subroutine  DEPCHK. 

13)  **  WARNING-13  **  MAXIMUM  RECONSTITUTION  TIME  = _ ,  BUT  SOME  ASSET 

NEEDS _ FOR  SOME  SUBSTITUTION.  THEREFORE.  SOME 

SUBSTITUTION  WILL  NEVER  BE  MADE  EXCEPT  AT  INITIAL  TIME. 

a)  Check  substitution  times. 

b)  Add  additional  reconstitutions  around  the  maximum  time  at  end  of  simulation  to  allow 
slow  substitutions. 
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c)  Check  parameters  in  RECONSTITUTION  EVENTS  and  LINKS  mnemonic  cards. 

d)  See  subroutine  ENCCHK. 

14)  “  WARNING-14  **  REINFORCEMENT  AT  TIME _ OCCURS  WITHIN  INTERNAL 

RECONSTITUTION  TIME  OF  LETHALITY  EVENT  AT  TIME _ 

a)  Time  of  reinforcement  may  be  inappropriate  in  relation  to  event  times. 

b)  Check  parameters  in  REINFORCEMENTS/LOSSES  mnemonic  card. 

c)  See  subroutine  EVNTBL. 

15)  **  WARNING-15  **  THE  MEAN  TIME  BETWEEN  FAILURES  FOR  ID _ IS  SHORT. 

a)  User  may  want  to  insert  more  reconstitution  events  into  time  gap  to  prevent  too  many 
failures  sitting  idle  before  repairs  are  processed. 

b)  Mean  time  between  failures  may  be  wrong. 

c)  Check  parameters  in  FAILURE  RATE  and  RECONSTITUTION  EVENTS 
mnemonic  cards. 

d)  See  subroutine  FAICHK. 

16)  **  WARNING-16  **  NO  REPAIRS  FOR  ITEMS  WHICH  CAN  FAIL  REPAIRABLY. 

a)  Repairs  of  failed  equipment  need  not  be  modeled. 

b)  Consider  using  repair  links,  if  appropriate. 

c)  Check  parameters  in  REPAIR  mnemonic  card. 

d)  See  subroutine  FAICHK. 

17)  **  WARNING-17  **  THE  FATIGUE  OPTION  CURRENTLY  KEEPS  ONLY  AVERAGES  OF 

SLEEP  TIME  OVER  ASSET  GROUPS.  ACCOUNTING  IS  PRECISE 
FOR  ASSET  GROUP  OF  ONE.  BUT  APPROXIMATE  FOR  OTHERS. 

a)  To  be  more  precise,  select  unique  names  for  ail  personnel  assets. 

b)  Check  parameters  in  ASSETS  and  FATIGUE  mnemonic  cards. 
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c)  See  subroutine  FGCHK. 


18)  **  WARNING-18  **  GRANULARITY  .LT.  0.0001  MAY  RESULT  IN  ROUND-OFF 

ERRORS. 

a)  Increase  input  granularity  in  mnemonic  card  to  avoid  round-off  errors. 

b)  Check  parameters  In  GRANULARITY  mnemonic  cards. 

c)  See  subroutine  GRANIN. 

19)  **  WARNING-19  **  LINK _ HAS  MORE  ITEMS  THAN  ALLOWED  BY  ITS  MAX  IN. 

a)  Reduce  number  of  assets  for  LINK _ 

b)  Deploy  assets  under  different  name;  make  link  a  DUMMYLINK. 

c)  Check  parameters  in  LINKS.  DEPLOYMENT,  and  NAMES  mnemonic  cards. 

d)  See  subroutine  LNKCHK. 

20)  “  WARNING-20  **  DUMMY  LINK  NOT  FOLLOWED  BY  SUBSTITUTES.  CHECK  LINK 

INPUT. 

a)  Is  this  meant  to  be  a  DUMMY  LINK? 

b)  Check  parameters  in  LINKS  mnemonic  card. 

c)  See  subroutine  LNKIN. 

21)  **  WARNING-21  **  SOME  LINKS  HAVE  NO  CORRESPONDINGLY  NAMED  ASSET{S). 

ASSUMING  "DUMMY  LINK(S)"  SEE  HOME  IDS  IN  LINK 
DEFINITION  TABLE. 

a)  If  not  intended  to  be  a  DUMMY  LINK,  add  name  to  asset  list. 

b)  The  LiNK  describes  a  task  oniy  and  not  a  particular  asset. 

c)  To  assure  the  modeling  of  a  HOMELINK,  a  link  name  must  be  identical  to  the  asset 
name  which  has  the  primary  responsibility  for  completing  the  link  task. 

d)  Check  parameters  in  LINKS  mnemonic  cards. 

e)  See  subroutine  LNKIN. 
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22)  **  WARNING-22  **  AT  LEAST  ONE  LINK  OPTIMIZATION  TERMINATED  BECAUSE 

ADDITION  OF  (DEGRADED?)  ASSETS  RESULTED  IN 
INSUFFICIENT  IMPROVEMENT.  DETAILS  WRITTEN  ON  FILE  8  IF 
"DUMPS"  IS  ON  (UNDER  "OUTPUT"  MNEMONIC). 

a)  Code  was  forced  to  use  increasingly  inefficient  assets.  Reached  efficiency  cut-off. 
Unit  effectiveness  may  be  slightly  underestimated. 

b)  See  subroutine  LNKOPT. 

23)  **  WARNING-23  **  WEAPON _ HAS  <=  0.  ROUND-ROUND  RELIABILITY. 

a)  ROUND-ROUND  reliability  should  be  between  zero  and  one. 

b)  Check  parameters  in  RELIABILITY  mnemonic  cards. 

c)  See  subroutine  RELIIN. 

24)  **  WARNING-24  **  WEAPON _ HAS  <=  0.  VOLLEY  RELIABILITY. 

a)  Volley  reliability  should  be  between  zero  and  one. 

%• 

b)  Check  parameters  in  RELIABILITY  mnemonic  cards. 

c)  See  subroutine  RELIIN. 

25)  **  WARNING-25  **  NUMBER  OF  REPLICATIONS  EXCEEDS  PACKING  CONSTANT 

FOR  WEAK  SEGMENT  STORAGE.  WEAK  SEGMENT  COUNT 
COULD  BE  QUITE  CONFUSED  BY  CHRONICALLY  WEAK 
SEGMENT. 

a)  Reduce  number  of  replications. 

b)  Ignore  weak  segment  count. 

c)  Check  parameters  in  LINKS  and  REPLICATIONS  mnemonic  cards. 

d)  See  subroutine  REPLIN. 

26)  **  WARNING-26  **  YIELD  OF  NUCLEAR  WEAPONS  IS  LESS  THAN  OR  EQUAL  TO 

ZERO. 
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a)  Check  parameters  in  YIELD  mnemonic  cards. 

b)  See  subroutine  RESTIN. 

27)  **  WARNING-27  **  FROM  REPAIR  CHECK  ROUTINE****  REPAIRS  AND 

DECONTAMINATIONS  CAN  ONLY  BE  INITIATED  AT  A 
RECONSTITUTION  EVENT.  SINCE  THE  LARGEST  TIME 
BETWEEN  RECONST.  EVENTS  IS  SIGNIFICANT  COMPARED 
TO  THE  REPAIRS  LISTED  BELOW,  IT  IS  POSSIBLE  FOR  A 
REPAIR  TO  FINISH  AND  THE  REPAIR  ASSETS  TO  SIT 
IDLE  FOR  SIGNIFICANT  TIMES  BEFORE  BEING  REASSIGNED. 
IF  SUCH  IDLE  TIME  WOULD  BE  AN  UNREAL  FACTOR  IN  THIS 
STUDY.  THE  REMEDY  IS  TO  PUT  RECONSTITUTION  EVENTS 
INTO  THE  SMALL  TIME  GAPS. 

a)  Add  additional  reconstitution  times. 

b)  Check  parameters  in  RECONSTITUTION  EVENT  and  REPAIR  mnemonic  cards. 

c)  See  subroutine  RPRCHK. 

28)  **  WARNING-28  **  NO  REPAIR  LINKS  GIVEN  FOR  ID _ . 

a)  If  playing  repair,  ensure  link  has  correct  parameters. 

b)  Item  may  not  be  repairable  type. 

c)  See  parameters  in  REPAIR  and  LINK  mnemonics  cards. 

d)  See  subroutine  RPRIN. 

29)  **  WARNING-29  **  DOES  NOT  IDENTIFY  A  UNIQUE  ASSOCIATED  ASSET  FOR 

NUCLEAR  POSTURE.  ID _ WAS  ARBITRARILY  SELECTED  AS 

THE  UNIQUE  CHOICE. 


a)  Nuclear  Blast  Vulnerability  parameters  for  asset  ID _ will  be  used  by  code  for  this 

asset. 


b)  if  desired,  input  a  unique  associated  asset  for  iD _ . 

c)  See  parameters  in  SHLDiN  mnemonic  card. 

d)  See  subroutine  SHLDIN. 

30)  **  WARNING-30  **  SETTING  RECONSTITUTION  YES  AFTER  THE  MOPP  MNEMONIC 

NEGATES  THE  EFFECT  OF  THE  PROXIMITY  OPTION. 

a)  RECONSTITUTION  YES  forces  the  code  to  put  all  personnel  in  MOPP  4,  thereby 
negating  the  proximity  option. 

b)  The  use  of  RECONSTITUTION  YES  option  has  become  obsolescent  in  view  of  the 
many  code  updates  which  have  been  made  to  improve  chemical  modeling. 

c)  See  parameters  in  MOPP  and  RECONSTITUTION  EVENT. 

d)  See  subroutine  TOXCHK. 

31)  **  WARNING-31  **  TIME  INTERVAL  BETWEEN  SHORTEST  MOPP  TIME  AND 

DOSAGE  UPDATE  TIME  FOR  TOXIC  WEAPON  IS  TOO  LONG. 

a)  Currently,  NUSSE  provides  dose  and  dosage  data  for  only  five  times  of  interest. 

When  assessing  the  dosages  of  personnel  at  the  target  across  time,  AURA  will  be 
forced  to  interpolate  on  the  data  provided  by  NUSSE  across  these  times.  The  analyst 
must  choose  NUSSE  times  of  interest  wisely. 

b)  Adjust  NUSSE  times  of  interest  to  be  close  to  times  of  interest  for  chemical  modeling 
in  AURA. 

c)  Dosage  levels  and/or  casualties  may  be  underestimated. 

d)  See  parameters  in  TOXIC  DISPERSION  DATA,  MOPP,  and  RECONSTITUTION 
mnemonic  cards. 

e)  See  subroutine  TOXCHK. 

32)  **  WARNING-32  **  NO  DATA  FOR  TOXIC  WEAPON  NUMBER. 

a)  Incorrect  or  insuffident  data  in  the  chemical  lethality  file  (Tape  4). 

b)  Has  the  TOXIC  DISPERSION  DATA  mnemonic  been  included  in  the  runstream? 
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c)  Check  parameters  in  WEAPONS  mnemonic  card. 

d)  See  subroutine  TOXiN. 

33)  **  WARNiNG-33  **  NUKE  HAS  <=0.  BLAST  YIELD. 

a)  Check  value  input  under  YIELD  mnemonic  card.  It  should  be  greater  than  0. 

b)  See  subroutine  YLDIN. 

34)  **  WARNING-34  **  NUKE  HAS  <=0.  RAD.  YIELD. 

a)  Check  value  input  under  YIELD  mnemonic  card.  It  should  be  greater  than  0. 

b)  See  subroutine  YLDIN. 

35)  **  WARNING-35  **  COULD  NOT  FIND  ASSET  NAMED  ON  SOME 

DEPLOYMENT  CARD(S).  "DUMMY  LINK(S)"  CREATED.  SEE  IDS 
IN  DEPLOYMENT  TABLE. 

a)  If  not  intended  to  be  a  DUMMY  LINK,  add  name  to  asset  list. 

b)  The  LINK  describes  a  task  only  and  not  a  particular  asset. 

c)  To  assure  the  modeling  of  a  HOMELINK,  a  link  name  must  be  identical  to  the  asset 
name  which  has  the  primary  responsibility  for  completing  the  link  task. 

d)  Check  parameters  in  LINKS  mnemonic  cards. 

e)  See  subroutine  DEPLIN. 


List  No.  2 


1)  **  ERROR-1  (ADDITIONAL)  ERRORS  IN  INPUT  FORMATS.  DETAILS  PRINTED 

WITHIN  LISTING  OF  MNEMONICS  AT  BEGINNING  OF  THIS  OUTPUT. 


a)  Look  in  preceding  section  of  output  (where  mnemonics  are  printed)  for  listing  of  errors. 

b)  See  subroutine  ENCCHK. 

2)  **  ERROR-2  **  AGENT  TYPE  FOR  WEAPON _ NOT  ALLOWED. 
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a)  G  or  GB,  V  or  VX,  H  or  HD  are  currently  Viewable  agent  types. 

b)  Must  use  one  of  three  s^ent  types  permitted  within  AURA. 

c)  Check  parameters  in  AGENT  mnemonic  card. 

d)  See  subroutine  AGNTIN. 

3)  **  ERROR-3  **  ASSET  # _ IS  BEING  USED  AS  BOTH  DUMMY  LINK  AND  HOMELINK. 

ILLEGAL.  FATAL  ERROR  IN  DEPLOY. 

a)  Current  procedure  does  not  require  listing  of  dummy  link  in  ASSETS.  Any  link  that  is 
deployed,  but  not  identified  as  an  asset,  is  automaticaily  classed  as  a  dummy  link. 

b)  Check  parameters  in  DEPLOYMENT  mnemonic  card. 

c)  See  subroutine  DEPLIN. 

4)  **  ERROR-4  **  AMBIGUOUS  ASSET  NAME _ CANNOT  BE  AN  INPUT  FOR 

EXPENDABLE.  STOP  IN  XPNDIN. 

a)  Asset  must  be  an  unique  (first)  name.  Redefine  asset  name  under  EXPENDABLE 
card  using  a  unique  name  and  not  a  secondary  name. 

b)  Check  parameters  in  EXPENDABLE  mnemonic  card. 

c)  See  subroutine  XPNDIN. 

5)  **  ERROR-5  **  CANNOT  INTERPOLATE  BETWEEN  LESS  THAN  2  DATA.  STOP  IN 

BRCKT2. 

a)  Check  toxic  lethality  input  file  for  missing  data. 

b)  Error  in  PRETOX  output  or  NUSSE  output? 

c)  See  subroutine  BRCKT2. 

6)  *•  ERROR-6  **  CANNOT  IDENTIFY  WHICH  IS  BEING  USED  AS  A  CHAIN  SEGMENT. 

a)  Check  CHAIN  input. 

b)  Check  parameters  in  CHAINS  mnemonic  card. 

c)  See  subroutine  CHNIN. 
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7)  **  ERROR-7  **  CHAINS  MUST  BE  DESIGNATED  BEFORE  THE  "REPAIR*  OPTION  CAN 

BE  USED. 

a)  Check  placement  of  CHAIN  card  in  runstream. 

b)  See  REPAIR  and  CHAINS  mnemonic  cards. 

c)  See  subroutine  RPRiN. 

8)  **  ERROR-8  **  CLOTHING  PARAMETERS  REQUIRE  MOPP  LEVEL  AND  PARAMETER 

VALUE. 

a)  Insert  clothing  parameters,  MOPP  level,  and  parameter  values  under  HEAT  STRESS 
card. 

b)  See  input  manual  for  format  of  HEAT  STRESS  input. 

c)  See  subroutine  HTSTIN. 

9)  *•  ERROR-9  **  COULD  NOT  FIND  LINK _ ,  (LINK  INPUT  MUST  PRECEDE  REPAIR). 

STOP  IN  RPRIN. 

a)  Check  order  of  LINKS  and  REPAIR  mnemonic  cards  in  runstream. 

b)  Link  name  may  either  be  misspeiied  or  not  inciuded.  if  needed,  add  iink  to  LiNKS 
section. 

c)  Check  parameters  in  LINKS  and  REPAIR  mnemonic  cards. 

d)  See  subroutine  RPRiN. 

10)  **  ERROR-1 0  **  CUMNRM  CALLED  WITH  ILLEGAL  VARIANCE  = _ . 

STOP  CALLED  FROM  CUMNRM. 

a)  Variance  values  must  be  positive.  Since  variance  is  square  of  (usual)  standard 
deviation  type  inputs,  this  error  might  indicate  code  malfunction. 

b)  See  subroutine  CUMNRM. 
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11)  **  ERROR-11  **  DIMENSION  TROUBLE.  TEMPORARY  STORAGE  (  MS1-MS6) 

IS  ALSO  USED  FOR  TEMPORARY  TARGET  POINTS  IN  LETHAL. 
BUT  6  *  MDX(3)IS  .LT.  TARGET  FG  (TGT  PTS  VS.  ASSETS). 
STOP  IN  NDXSET. 


a)  May  need  to  increase  array  dimensions,  if  this  is  not  possible,  reduce  number  of 
target  points. 

b)  See  subroutines  NDXSET. 

12)  **  ERROR-12  **  DEPLOYMENT  BY  SECONDARY  NAME  IS  NOT  ALLOWED.  USE 

PRIMARY  NAME  FOR  DEPLOYMENT. 

a)  Must  deploy  target  using  unique  (first)  name  in  asset  list. 

b)  Check  parameters  in  DEPLOYMENT  mnemonic  card. 

c)  See  subroutine  DEPLIN. 

13)  **  ERROR-13  **  _ DOES  NOT  IDENTIFY  A  UNIQUE  WEAPON. 

a)  Must  identify  weapon  by  unique  (first)  name  when  specifying  use  (via  ROUND  or 
VOLLEY). 

b)  Check  parameters  in  WEAPONS  mnemonic  card. 

c)  See  subroutine  RNDIN. 

14)  **  ERROR-14  *•  ERROR  IN  AGENT  TYPE  INPUT.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  agent  type  input  in  runstream,  AGENT  card. 

d)  Must  use  one  of  three,  currently  allowable  s^ent  types. 

e)  See  input  manual  for  proper  format  of  AGENT  inputs. 

f)  See  subroutine  AGNTIN. 
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15)  **  ERROR-15  ERROR  IN  ALARM  INPUT.  FAULTY  CARD  [  ]. 


a)  Line  of  input  with  error  wiii  be  output  in  brackets. 

b)  See  iine  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  ALARM  input  in  runstream. 

d)  See  input  manuai  for  proper  format  of  ALARM  inputs. 

e)  See  subroutine  ALRMIN. 

16)  **  ERROR-16  **  ERROR  iN  CHAiN  INPUT.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  iine  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  CHAIN  input  in  runstream. 

d)  See  input  manual  for  proper  format  of  CHAiN  inputs. 

e)  See  subroutine  CHNIN. 

17)  **  ERROR-17  **  ERROR  AFTER  CONTAMINATED  USAGE  CARD.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  CONTAMINATED  USAGE  input  in  runstream. 

d)  See  input  manual  for  proper  format  of  CONTAMINATED  USAGE  inputs. 

e)  See  subroutine  CNTUIN. 

18)  *•  ERROR-18  **  ERROR  IN  CNVDMG.  ATTEMPTED  DATA  TYPE  1  OR  4, 

WEAPON.  ASSET,  HOB.  COVER,  KILL  = _ 

a)  Data  type  one  and  four  are  now  being  used  for  smart  munitions.  Change  lethality 
input  code  number  on  input  file  (unit  2). 

b)  See  input  manuai  for  format  and  data  types  allowed. 

c)  See  subroutine  CNVDMG. 
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19)  **  ERROR-19  **  ERROR!  WEAPON _ AGAINST  TARGET _ HAS  LETHAL 

RADII  =  0.  ILLEGAL  (PK  MAY  =  0;  NOT  RADII). 

a)  Correct  data  input.  For  negligible  lethal  radii  use  a  value  on  the  order  of  0.01 . 

b)  Check  parameters  in  CONVENTIONAL  LETHALITY  DATA  mnemonic  card. 

c)  See  subroutine  CONVIN. 

20)  **  ERROR-20  **  ERROR!  WEAPON _ AGAINST  TARGET _ .  RADII  MUST  IN 

NONDECREASING  ORDER. 

a)  See  input  manual  for  proper  format.  Make  necessary  changes  to  conventional  lethality 
file. 

b)  Check  parameters  in  CONVENTIONAL  LETHALITY  DATA  mnemonic  card. 

c)  See  subroutine  CONVIN. 

21)  **  ERROR-21  **  ERROR  IN  CONVENTIONAL  LETHALITY  INPUT. 

a)  Check  format  and  syntax  of  lethality  input  in  runstream. 

b)  See  input  manual  for  proper  format. 

c)  Check  parameters  in  CONVENTIONAL  LETHALITY  DATA  mnemonic  card. 

d)  See  subroutine  CONVIN. 

22)  **  ERROR-22  **  CANNOT  USE  A  COMPOUND  LINK  AS  A  PART  OF  A  COMPOUND 

LINK. 

a)  Redefine  functional  structure. 

b)  Check  parameters  in  COMPOUND  LINKS  mnemonic  cards. 

c)  See  subroutine  CPLKIN. 

23)  **  ERROR-23  **  ERROR  IN  COMPOUND  LINK  INPUT.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 
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c)  Check  format  and  s^tax  of  COMPOUND  LINKS  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  CPLKIN. 

24)  **  ERROR-24  **  ERROR  IN  CREW  INPUT.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  CREW  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  CRWIN. 

25)  **  ERROR-25  **  REPAIRABLE  ASSET  # _ ,  HAS  LIGHT/MEDIUM/HEAVY  DAMAGE 

LETHALITY  FOR  WEAPON  #  __BUT  NOT  FOR  OTHER  WEAPONS. 
MUST  HAVE  FOR  ALL  OR  NONE. 

a)  Update  each  weapon  with  the  same  type  of  input  in  the  conventional  lethality  file. 

b)  Check  parameters  in  CONVENTIONAL  LETHALITY  DATA  mnemonic  card. 

c)  See  subroutine  CVLCHK. 

26)  **  ERROR-26  **  ERROR  AFTER  DECISION  CARD.  FAULTY  CARD  [  ]. 

a)  Line  of  ir^  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  input  after  DECISION  RULES  card  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  DCSRLN. 

27)  **  ERROR-27  **  ERROR  IN  TOXIC  DEGRADATION  INPUT.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  DEGRADATION  input. 
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d)  See  input  manual  for  proper  format. 

e)  See  sidsroutine  DEQRIN. 

28)  “  ERROR-28  **  ID#  _  WAS  INPUT  AS  A  SECONDARY  EXPLOSIVE.  IT  CANNOT  BE 

IN  A  LINK.  RUN  CHANGED  TO  DEBUG. 

a)  Secondary  explosion  is  not  a  task.  Remove  from  LINKS  section. 

b)  Check  parameters  in  ASSETS  and  WEAPON  mnemonic  cards. 

c)  See  subroutine  DEP2ND. 

29)  **  ERROR-29  **  SECONDARY  EXPLOSIVE  ID  #_,  WAS  DEPLOYED  BY  USER  AT 

TARGET  POINT.  ILLEGAL  RUN  CHANGED  TO  DEBUG. 

a)  Secondary  explosive  need  not  be  deployed.  The  location  of  an  asset  which  has  been 
defined  as  having  the  potential  to  become  a  secondary  explosion  needs  to  be 
deployed. 

b)  See  subroutine  DEP2ND. 

30)  **  ERROR-30  **  ERROR  ON  DELIVERY  ERROR  INPUT.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  DELIVERY  ERROR  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  DLVRIN. 

31)  **  ERROR-31  •*  TARGET  POINT _ CONTAINS  A  DUMMY  LINK _ WHICH  HAS 

NO  SUBSTITUTES.  SUCH  A  LINK  CANNOT  BE  DEPLOYED!!! 

a)  A  DUMMY  L!NK  which  has  no  substitutes  may  not  be  deployed.  Either  add 
substitutes  or  don’t  deploy  it 

b)  See  si^routine  DUMCHK. 
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32)  **  ERROR-32  ** _ WAS  DEPLOYED  AT  TARGET  POINT _ ,  BUT  WAS  NOT 

INPUT  AS  AN  ASSET  OR  A  LINK. 

a)  Define  entity  deployed  at  target  point  as  an  ASSET  or  a  LiNK  or  tx>th. 

b)  See  subroutine  DUMCHK. 

33)  **  ERROR-33  **  ERROR  IN  FAILURE  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  bracked. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  FAiLURE  RATE  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  FAILiN. 

34)  **  ERROR-34  **  ASSET  NAMED _ HAS  MORE  THAN  ONE  ELEMENT. 

CURRENTLY  NOT  ALLOWED  FOR  PERSONNEL  IN  STOCHASTIC 
MODE. 

a)  Two  or  more  assets  can  be  deployed  at  the  same  point,  but  they  must  have  unique 
names  in  order  to  run  stochastic  mode. 

b)  Check  parameters  in  ASSET  and  MODE  mnemonic  cards. 

c)  See  subroutine  FGCHK. 

35)  **  ERROR-35  **  ERROR  IN  GRANULARITY  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  wiil  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  GRANULARiTY  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  GRANIN. 
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36)  **  ERROR-36  **  ERROR  IN  HEAT  STRESS  INPUT.  FAULTY  CARD.  [  ]. 


a)  Line  of  input  with  error  will  be  output  in  bradcets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  HEAT  STRESS  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  HTSTIN. 

37)  **  ERROR-37  **  DO  NOT  HAVE  A  METEOROLOGICAL  INTERVAL  THAT  INCLUDES 
THE  RECONSTITUTION  AT  TIME  .  STOP  IN  HTSTR. 


a)  Adjust  starting  and  stopping  times  of  meteorological  period  under  HEAT  STRESS  card 
so  that  ail  reconstitution  times  occur  within  some  meteorological  interval. 

b)  See  subroutine  HTSTR. 

38)  **  ERROR-38  **  ERROR  IN  READING  DOSE-TIME  DEGRADATION  DATA  ON  UNIT  11. 

FAULTY  CARD.  (  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Format  for  the  DEGRADATION  data  in  unit  #  1 1  is  provided  in  Aopendix  B  in  Volume 
11  of  AURA  Programmer/Analyst  Guide. 

d)  See  subroutine  IDPIN. 

39)  **  ERROR-39  **  ERROR  IN  NUKE  DEGRADATION  -  LINK  ASSOCIATION  INPUT  IS  NOT 

KNOWN  AS  A  LINK  (LINKS  MUST  BE  INPUT  FIRST). 

a)  Change  order  of  input  runstream  to  input  LINKS  first. 

b)  See  subroutine  IDPIN. 

40)  **  ERROR-40  ERROR  IN  SUBLETHAL  DOSE  DEGRADATION  INPUT. 

FAULTY  CARD  (  ]. 
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a)  Lira  of  input  with  error  wiil  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  SUBLETHAL  DOSE  DEGRADATION  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  IDPiN. 

41)  •*  ERROR-41  **  ERROR  AFTER  INTERNAL  CARD.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  input  after  INTERNAL  RECONSTITUTION  TIMES  card  in 
runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  INTNIN. 

42)  **  ERROR-42  **  ERROR  IN  HEAT  STRESS  INPUT.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  HEAT  STRESS  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  iVDIN. 

43)  **  ERROR-43  **  LINK _ HAS  BOTH  PERSONNEL  AND  NONPERSONNEL.  NOT 

ALLOWED. 

a)  Reconfigure  links.  Personnel  cannot  substitute  for  nonpersonnel  and  vice  versa. 
Check  LINKS  section  in  runstream. 

b)  See  subroutine  LNKCHK. 

44)  **  ERROR-44  **  THE  NAME _ DOES  NOT  UNIQUELY  IDENTIFY  ONE  ASSET  FOR 

LINK  DEFINITION.  ILLEGAL.  RUN  CHANGED  TO  DEBUG  BY  LNKIN. 
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a)  Must  use  unique  name  and  not  a  secondary  name.  Check  names  under  ASSETS 
mnemonic  card  in  runstream. 

b)  See  input  manual  for  proper  format. 

c)  See  subroutine  LNKIN. 

45)  **  ERROR-45  **  FIRST  CARD  AFTER  LINKS  CARD  MUST  CONTAIN  A  LINK  NAME 

(NOTA$). 

a)  Check  format  of  LINK  input  in  runstream. 

b)  See  input  manual  for  proper  format. 

c)  See  subroutine  LNKIN. 

46)  **  ERROR-46  **  ERROR  IN  INPUT  OF  ASSOCIATED  LINK  FOR  LINK _ . 

FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  bradtets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  LINKS  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  LNKIN. 

47)  **  ERROR-47  **  ERROR  AFTER  LINKS  CARD  IN  SUBSTITUTES  FOR  LINK _ 

a)  Check  format  and  syntax  of  substitutes  input  in  runstream. 

b)  See  input  manual  for  proper  format. 

c)  See  subroutine  LNKIN. 

48)  **  ERROR-48  **  A  LINK  NAMED _ WAS  INPUT  AS  AN  ASSOCIATED  LINK 

FOR  LINK _ .  BUT  WAS  NEVER  DEFINED. 

a)  Define  associated  link  in  the  LINKS  section  of  runstream. 

b)  See  input  manual  for  proper  format. 

c)  See  subroutine  LNKIN. 
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49)  “  ERROR-49  **  ERROR  IN  LINKS  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  wili  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  LINKS  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  LNKIN. 

50)  **  ERROR-50  **  ERROR  IN  LINK  INPUT.  SUBSTITUTION  CARD  FOR  LINK _ NOT 

FOLLOWED  BY  PROPER  SUBSTITUTION  TIMES  AND 
SUBSTITUTABILITY  CARDS. 

a)  Check  format  and  syntax  of  LINKS  input  in  runstream.  Effectiveness  and  substitution 
time  input  must  follow  each  substitute  input  in  runstream. 

b)  Check  that  the  number  of  each  set  of  desaiptions  is  correct. 

c)  See  input  manual  for  proper  format. 

d)  See  subroutine  LNKIN. 

51)  **  ERROR-51  **  ERROR  IN  LINK  INPUT  FOR  LINK _ .  EFFECTIVENESS  CANNOT 

DECREASE  WITH  ADDITIONAL  ALLOCATION. 

a)  Maximum  effectiveness  cannot  be  less  than  minimum  effectiveness. 

b)  Check  format  and  syntax  of  LINKS  input  in  mnstream. 

c)  See  subroutine  LNKIN. 

52)  **  ERROR-52  **  ERROR  IN  LINK  INPUT  FOR  LINK _ 

MAXIMUM  EFFECTIVENESS  =  0.0.  PROBABLE  ERROR  IN  INPUT 
FORMAT. 

a)  Check  effectiveness  input.  Maximum  effectiveness  cannot  be  zero. 

b)  Check  format  and  syntax  of  LINKS  input  in  runstream. 

c)  See  subroutine  LNKIN. 
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53)  **  ERROR-53  **  ERROR  IN  LINK  INPUT  FOR  LINK _ NUMBER  FOR  MAXIMUM 

CAPABILITY  CANNOT  BE  LESS  THAN  MINIMUM. 

a)  Check  link  input  in  runstream. 

b)  Check  format  and  syntax  of  LINKS  input  in  runstream. 

c)  See  subroutine  LNKIN. 

54)  **  ERROR-54  **  ID _ HAS  MORE  THAN  ONE  HOMELINK. 

a)  There  can  only  be  one  HOMELINK  for  each  link.  Check  LINKS  input. 

b)  See  subroutine  LNKSET. 

55)  **  ERROR-55  **  ERROR  IN  LETHAL  DOSE  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  wiii  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  DOSE  PARAMETERS  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  LTHDIN. 

56)  **  ERROR-56  **  ERROR  IN  INPUT  IN  DOSE  BINS  (UNDER  DOSE  PARAMETERS 

MNEMONIC).  MUST  HAVE  TEN  BIN  VALUES. 

a)  Check  format  of  DOSE  PARAMETERS  input  in  runstream. 

b)  See  subroutine  LTHDIN. 

57)  **  ERROR-57  **  LAST  POINTER  (MDX(24))  INTO  COMMON  BLOCK  /MAGNUS/  =  , 

EXCEEDS  SIZE  OF  RA  ARRAY  EVEN  BEFORE  WEAPON  EFFECTS 
DATA  AND  DYNAMIC  STORAGE  BEGINS!!! 

a)  increase  dimensions  of  array  RA. 

b)  See  subroutine  MACSET. 
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58)  **  ERROR-58  **  ERROR  ON  MISS  DISTANCE  INPUT.  FAULTY  CARD.  [  ]. 


a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  fomiat  and  syntax  of  MISS  DISTANCE  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  MISDIN. 

59)  **  ERROR-59  **  ERROR  AFTER  MODE  CARD.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  input  after  MODE  card  in  runstream. 

d)  See  input  manuai  for  proper  format. 

e)  See  subroutine  MODEIN. 

60)  **  ERROR-60  **  ERROR  IN  MOPP  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  MOPP  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  MOPPIN. 

61)  **  ERROR-61  **  ASSET  #  _  HAS  NO  UNIQUE  NAME. 

a)  Each  asset  must  have  at  least  one  unique  name,  insert  unique  name  under  NAMES 
card  for  asset. 

b)  See  subroutine  NAMES. 


62)  **  ERROR-62  “  ERROR  IN  SUBROUTINE  NORMAL,  NUM  = _ . 

a)  Internal  code  error. 

b)  Random  numbers  are  generated  through  subroutine  UNIFORM.  See  uniform  for 
possible  program  error. 

c)  See  subroutine  NORMAL 

63)  **  ERROR-63  **  ERROR  SPECIFYING  OUTPUT  OPTIONS.  ERRANT  CARD _ 

a)  Check  format  of  output  options.  See  input  manual  for  format  of  OUTPUT  options. 

b)  See  input  manual  for  proper  format. 

c)  See  subroutine  OOPTIN. 

64)  **  ERROR-64  **  NO  CHAIN  WAS  OPERANT.  ERROR  AT  RECONSTITUTION  TIME 


a)  No  chain  specified  for  reconstitution.  Check  chain  inputs  and  chain  operant  times  if 
used. 

b)  See  subroutine  OPTMIZ. 

65)  **  ERROR-65  **  CANNOT  USE  A  COMPOUND  LINK  AS  A  BRANCH  OF  AN  ORLINK. 

a)  Redefine  functional  structure. 

b)  Check  parameters  in  LINKS  and  ORLINK  input. 

c)  See  subroutine  ORLIN. 

66)  **  ERROR-66  **  ERROR  IN  ORLINK  INPUT.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  ORLINKS  input  in  runstream. 

d)  See  input  manual  for  proper  format. 
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e)  See  subroutine  ORLIN. 


67)  **  ERROR-67  **  ID#  WAS  INPUT  AS  SECONDARY  EXPLOSIVE.  IT  CANNOT  BE 
IN  A  LINK.  RUN  CHANGED  TO  DEBUG. 


a)  Secondary  explosions  can  only  be  input  as  a  weapon  and  an  asset. 

b)  See  subroutine  PRE2ND. 

68)  **  ERROR-68  **  SECONDARY  EXPLOSIVE  ID# _ WAS  DEPLOYED  BY  USER  AT 

TARGET  POINT.  ILLEGAL.  RUN  CHANGED  TO  DEBUG. 


a)  Assets  that  are  potential  sources  of  secondary  explosions  must  be  deployed. 

b)  See  subroutine  PRE2ND. 

69)  **  ERROR-69  **  REPAIR  OF  ID  _  REQUIRES  LINK  _  TWICE.  ILLEGAL.  RUN 

CHANGED  TO  DEBUG  BY  PRECHK. 

a)  A  link  may  never  be  used  twice  in  the  same  chain.  Specify  two  different  links. 

b)  See  subroutine  RPRCHK. 

70)  **  ERROR-70  **  ERROR  IN  PERSISTENCE  MULTIPLIER  INPUT.  FAULTY  CARD  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  PERSISTENCE  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  PRSFIN. 

71)  **  ERROR-71  •*  NO  TOXIC  DATA  FOR _ .  REMEMBER  TOXIC  DISPERSION  CARD 

(WHICH  CAUSES  UNIT  4  TO  BE  READ)  MUST  PRECEDE 
PERSISTENCE  INPUT. 
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a)  TOXIC  DISPERSION  mnemonic  card  must  come  before  the  PERSISTENCE 
mnemonic  card  in  the  runstream. 

b)  See  subroutine  PRSFIN. 

72)  **  ERROR-72  **  ERROR  IN  RECONSTITUTION  EVENT  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  RECONSTITUTION  EVENTS  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  RECIN. 

73)  **  ERROR-73  **  REINFORCEMENT  WAS  NOT  DEPLOYED.  CODE  HAS  NO  PLACE 

TO  PUT  ASSET  WHEN  IT  ARRIVES. 

a)  Reinforcement  assets  must  be  declared  under  the  ASSET  mnemonic  and  deployed 
like  other  assets. 

b)  See  input  manual  for  proper  format. 

c)  See  subroutine  REICHK. 

74)  *•  ERROR-74  **  ERROR  IN  REST  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  REST  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  RESTIN. 

75)  •*  ERROR-75  **  NUMBER  OF  WEAPON  EMPLOYMENTS  EXCEEDS  MAX(290). 

STOP  IN  ROUND  INPUT. 

a)  Reduce  the  number  of  weapons  to  less  than  290. 

b)  See  subroutine  RNDIN. 
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76)  *•  ERROR-76  **  ERROR  AFTER  SEEDS  CARD.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  In  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  input  after  SEEDS  card  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  RNSDIN. 

77)  **  ERROR-77  **  ERROR  IN  PROGRAM.  REPAIR  SUBROUTINE  CALLED  FOR 

NONREPAIRABLE  ITEM.  ASSET  #.  DAMAGE  LEVEL.  CODE  NUMBER. 

a)  Check  that  asset  is  not  personnel.  Verify  assets  in  ASSETS  mnemonic. 

b)  See  subroutine  RPORDR. 

78)  **  ERROR-78  **  GENERAL  REPAiR  CARD  NOT  FOLLOWED  BY  $LINK.  LEVEL  OR 

$SUBCHAiN,  LEVEL. 

a)  Check  format  and  syntax  of  repair  input  in  runstream. 

b)  See  input  manual  for  correct  format  of  REPAIR  Input. 

c)  See  subroutine  RPRIN. 

79)  **  ERROR-79  **  ERROR  AFTER  REPAIR  CARD.  FAULTY  CARD.  (  J. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  input  after  REPAIR  card. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  RPRIN. 

80)  ERROR-80  **  SUBCHAINS  MAY  ONLY  CONTAIN  LINKS  OR  CREWS. 

FAULTY  ITEM  [  ]. 

a)  Redefine  functional  structure. 
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b)  Check  parameters  in  SUBCHAINS  input  in  runstream. 

c)  See  subroutine  SBCIN. 

81)  *•  ERROR-81  **  ERROR  IN  SUBCHAIN  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  SUBCHAINS  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  SBCIN. 

82)  **  ERROR-82  **  NUCLEAR  POSTURE  CODE  #1  MUST  BE  "OPEN". 

a)  Possible  typographical  error.  Check,  nuclear  posture  inputs  in  nuclear  vulnerability  file. 

b)  See  input  manual  for  proper  format  of  SHIELDING  inputs. 

c)  See  subroutine  SHLDIN. 

83)  **  ERROR-83  **  NUCLEAR  POSTURE  CODE  #2  MUST  BE  "OPEN-NO  THERMAL 

EXPOSURE". 

a)  Possible  typographical  error.  Check  nuclear  posture  inputs  in  nuclear  vulnerability  file. 

b)  See  input  manual  for  proper  format  of  SHIELDING  inputs. 

c)  See  subroutine  SHLDIN. 

84)  **  ERROR-84  **  NUCLEAR  POSTURE  CODE  #3  MUST  BE  "FOXHOLE". 

a)  Possible  typographical  error.  Check  nuclear  posture  inputs  in  nuclear  vulnerability  file. 

b)  See  input  manual  for  proper  format  of  SHIELDING  inputs. 

c)  See  subroutine  SHLDIN. 

85)  *•  ERROR-85  **  NUCLEAR  POSTURE  CODES  1-3  (OPEN.  OPEN  -  NO  THERMAL. 

FOXHOLE  )  MAY  NOT  HAVE  AN  ASSOCIATED  ASSET  (E.G..  A 
VEHICLE). 


151 


a)  Postures  1-3  are  already  predefined.  Use  integer  vaiues  4-61  to  define  other  nuclear 
postures. 

b)  See  input  manuai  for  proper  format  of  SHIELDiNG  inputs. 

c)  See  subroutine  SHLDiN. 

86)  **  ERROR-86  **  ERROR  IN  SHIELD.  CODE  NUMBER _ NOT  ALLOWED. 

a)  See  AURA  Volume  II  for  all  currently  allowable  nuclear  posture  codes. 

b)  See  input  manual  for  proper  format  of  SHIELDING  inputs. 

c)  See  subroutine  SHLDIN. 

87)  **  ERROR-87  **  ERROR  IN  THERMAL  (NUCLEAR)  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  THERMAL  input  In  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  THRMIN. 

88)  **  ERROR-88  **  ERROR  AFTER  TIREDNESS  CARD.  ASSETS  MUST  BE  PERSONNEL. 

a)  Check  that  asset  name  has  been  defined  under  ASSET  card  as  personnel. 

b)  See  subroutine  TIREIN. 

89)  **  ERROR-89  **  ERROR  IN  TOXIC  KILL  CRITERIA  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  TOXIC  KILL  CRITERIA  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  TKCIN. 
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90)  **  ERROR-90  **  ERROR  IN  TOXIC  LETHALITY  INPUT.  X,  Y.  AND  T.  (DOWNWIND, 

CROSSWIND,  AND  TIME)  MUST  BE  INCREASING  ARRAYS. 

a)  Check  toxic  lethality  inputs  in  PRETOX  output  file.  X,  Y,  and  T  must  be  increasing 
arrays. 

b)  May  be  an  error  in  the  toxic  iethaiity  file  (TAPE  4). 

c)  See  subroutine  TOXIN. 

91)  **  ERROR-91  **  ERROR  IN  TOXIC  LETHALITY  INPUT.  FAULTY  CARD.  [  ]. 

a)  Check  format  and  syntax  of  toxic  lethality  input  in  runstream  on  Unit  No.  4. 

b)  See  subroutine  TOXIN. 

92)  **  ERROR-92  **  ERROR  IN  TRACE  INPUT.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  wiii  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  TRACE  LINK  USAGE  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  TRACiN. 

93)  *•  ERROR-93  **  LINK _ IS  SIMULTANEOUSLY  USED _ TIMES  IN  CHAIN _ 

a)  A  link  can  oniy  appear  once  in  any  given  chain.  Redefine  functional  structure. 

b)  See  subroutine  USDCHK. 

94)  **  ERROR-94  **  NUMBER  OF  EXPENDABLE  ITEMS  EXCEEDS  MAX  (@NXP).  STOP 

IN  XPNDIN. 

a)  Reduce  the  number  of  expendable  items  to  less  than  maximum  (@NXP). 

b)  See  subroutine  XPNDIN. 

95)  **  ERROR-95  **  ERROR  IN  EXPENDABLE  INPUT.  FAULTY  CARD.  [  ]. 
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a)  Line  of  input  with  error  wiii  be  output  in  brackets. 

b)  See  ilne  of  Input  where  error  occurred. 

c)  Check  format  and  syntax  of  EXPENDABLE  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  XPNDIN. 

96)  **  ERROR-96  **  EXCEEDED  MEMORY  DURING  INPUT  DOSE-TIME  PERFORMANCE 

DEGRADATION  DATA. 

a)  Reduce  the  input  data. 

b)  Redimension  RA. 

c)  See  subroutine  IDPIN. 

97)  **  ERROR-97  **  ERROR  IN  DOSE  BINS.  BINS  MUST  INCREASE  IN  DOSE. 

a)  Values  of  the  bins  must  be  sequentially  increasing. 

b)  See  input  manual  for  proper  format  of  DOSE  PARAMETERS  inputs. 

c)  See  subroutine  BINSET. 

98)  **  ERROR-98  **  DOSE  BINS  MAY  NOT  EXCEED  DOSMAX. 

a)  Dose  bins  may  not  exceed  the  maximum  dosage. 

b)  Reduce  dose  bins  or  increment  DOSMAX. 

c)  See  subroutine  BINSET. 

99)  **  ERROR-99  **  MUST  INPUT  LINKS  BEFORE  CHAINS. 

a)  Check  input  runstream  for  correct  ordering  of  CHAINS  and  LINKS. 

b)  See  subroutine  CHNIN. 

100)  **  ERROR-1 00  **  DEPLOYMENT.  WEAPON  EFFECTS  DELIVERY  ERRORS  AND  TLE 

MUST  PRECEDE  ROUND  AND  VOLLEY.  WHEN  IN  CULL  MODE. 


a)  Check  order  of  mnemonic  cards. 

b)  See  subroutine  CONVIN. 

101)  **  ERROR-1 01  **  TOO  MANY  CREWS.  MAX  =  (@NCR). 

a)  Maximum  number  of  crews  allowed  is  (@NCR).  Reduce  number  of  crews  or 
redimension  code. 

b)  See  subroutine  CRWIN. 

102)  **  ERROR-1 02  **  EXCEEDED  STORAGE  FOR  CREW  DATA. 

a)  Reduce  number  or  size  of  crews  or  redimension  code. 

b)  See  subroutine  CRWIN. 

103)  **  ERROR-1 03  **  CODE  CURRENTLY  DOES  NOT  ALLOW  MIXING  OF  NUCLEAR  AND 

CHEMICAL  ATTACKS  IN  THE  SAME  ENCOUNTER. 

STOP  CALLED  FROM  EVNCHK. 

a)  AURA  currently  does  not  allow  the  modeling  of  both  CHEMICAL  and  NUCLEAR 
attacks  within  the  same  encounter.  Two  separate  runs  must  be  made. 

b)  See  subroutine  EVNCHK. 

104)  **  ERROR-1 04  **  ERROR  IN  INTERNAL  RECONSTITUTION  INPUT.  NUMBER  OF 

TIMES  MUST  BE  .GT.  0  AND  .LT.  48. 

a)  INTERNAL  RECONSTITUTION  card  must  be  followed  by  at  least  1 ,  but  no  more  than 
48,  time  values. 

b)  See  subroutine  INTNIN. 

105)  **  ERROR-1 05  **  ASSET _  CANNOT  SUBSTITUTE  INTO  LINK _ AT  .GT.  100%. 

a)  Maximum  effectiveness  of  a  link  is  1 00%.  Check  input  for  possible  typographical  error. 

b)  See  subroutine  LNKCHK. 
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106)  **  ERROR>106  **  MODE  CARD  WITH  THE  CULL  OPTION  MUST  PRECEDE  THE 

ROUND  AND  VOLLEY  INPUT. 

a)  Cull  option  must  be  set  before  input  of  incoming  rounds.  Check  order  of 
VOLLEY/ROUND  inputs  in  runstream. 

b)  See  subroutine  MODEIN. 

107)  **  ERROR-1 07  **  TOO  MANY  ORLINKS.  MAX  =  (@ORL). 

a)  Reduce  the  number  of  orlinks  to  less  than  (@ORL)  or  redimension  code. 

b)  Check  ORLINKS  input  in  runstream. 

c)  See  subroutine  ORLIN. 

108)  **  ERROR-1 08  **  MAXIMUM  MOPP  = _ .  SOMEHOW.  A  MOPP  LEVEL  WAS 

DEFINED  ABOVE  THE  ALLOWED,  CHECK  DEPLOYMENT,  MOPP, 
TOXIC  KILL  CRITERIA  OR  REST  INPUTS. 

a)  Reduce  the  number  of  MOPP  postures  to  eight  or  less. 

b)  See  subroutine  PRECHK. 

109)  **  ERROR-1 09  **  TOO  MANY  SUBCHAINS.  MAX  =  (@NSC). 

a)  Reduce  the  number  of  subchains  to  less  than  (@NSC)  or  redimension  code. 

b)  See  subroutine  SBCIN. 

110)  **  ERROR-1 10  **  TOXIC  WEAPON _ DOES  NOT  HAVE  A  SHORT  TIME  VAPOR 

DOSAGE  SPECIFIED.  THINGS  START  HAPPENING  BY _ 


a)  Rerun  NUSSE  using  an  earlier  time  of  interest  close  to  but  not  greater  than  the  time 
specified. 

b)  See  subroutine  TOXCHK. 
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111)  **  ERROR-111  **  TIME  INTERVAL  BETWEEN  LONGEST  MOPP  TIME  AND  DOSAGE 


UPDATE  TIME  FOR  TOXIC  WEAPON  IS  LONG. 


a)  Compare  maximum  MOPP  time  to  the  output  times  used  in  the  NUSSE  model.  Pick  a 
NUSSE  output  time  slightly  greater  than  the  maximum  MOPP  time. 

b)  May  need  to  reset  INTERNAL  or  RECONSTITUTION  times  to  shorten  this  time 
intenral. 

c)  See  subroutine  TOXCHK. 

112)  **  ERROR-112  **  NO  TOXIC  DISPERSION  DATA  FOR  WEAPON _ . 

a)  Verify  that  weapon  name  in  runstream  and  lethality  file  is  the  same. 

b)  See  subroutine  WEPCHK. 

113) **  ERROR-1 13  **  ERROR  IN  TOXIC  WEAPONS.  WEAPONS  THAT  SHARE  THE  SAME 

TOXIC  DISPERSION  FILES.  WERE  NOT  DECLARED  TO  BE  THE 
SAME  AGENT.  FOUND  IN  WEPCHK. 

a)  Weapons  sharing  toxic  dispersion  file  must  be  the  same  agent  type.  Redefine  agent 
types  under  the  AGENT  mnemonic  or  input  separate  dispersion  files. 

b)  See  subroutine  WEPCHK. 

1 14)  **  ERROR-1 14  **  ASSET _ REQUIRES  MORE  THAN  27  REPAIR  LINKS.  ILLEGAL. 

STOP  IN  PRECHK. 

a)  Reduce  the  number  of  repair  links  required  to  repair  the  given  asset. 

b)  See  input  manual  for  proper  format  of  REPAIR  Inputs. 

c)  See  subroutine  PRECHK. 

115)  **  ERROR-115  **  ASSET _ WAS  DEFINED  AS  PERSONNEL  BUT  WAS  GIVEN 

REPAIR  PARAMETERS.  ILLEGAL. 
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.  a)  Personnel  cannot  be  repaired.  Check  inputs  under  REPAIR, 

b)  See  subroutine  RPRIN. 

116)  **  ERROR-116  **  FORMAT  ERROR  IN  ACQUISITION  PROBABILITY  INPUT. 

FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  ACQUISITION  PROBABILITY  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  ACQRIN. 

117)  **  ERROR-117  **  FORMAT  ERROR  IN  TIME  INPUT  FOR  CHAIN _ . 

FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Must  have  even  number  of  reals  and  no  integers. 

d)  Check  format  and  syntax  of  CHAIN  input  in  runstream. 

e)  See  input  manual  for  proper  format. 

f)  See  subroutine  CHNIN. 

118)  **  ERROR-1 18  **  FORMAT  ERROR  IN  DEPLOYMENT  OF  TARGET  NO. _ 

FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  DEPLOYMENT  Input  In  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  DEPLIN. 

119)  **  ERROR-119  **  FORMAT  ERROR  ON  FATIGUE  INPUT  FOR _ . 
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a)  Check  format  of  FATIGUE  input  in  runstream. 

c)  See  input  manual  for  proper  format. 

b)  See  subroutine  FATIN. 

120)  **  ERROR-120  **  FORMAT  ERROR  AFTER  INCOMING  CARD. 

a)  Check  format  and  syntax  of  input  after  INCOMING  FIRE  DIRECTION  mnemonic  card 
in  runstream. 

b)  See  input  manual  for  proper  format. 

c)  See  subroutine  INCIN. 

121)  **  ERROR-121  **  FORMAT  ERROR  AFTER  OFFSET  CARD.  FAULTY  CARD.  [  ). 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  input  after  OFFSET  card  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  OFFSIN. 

122)  **  ERROR-122  **  FORMAT  ERROR  AFTER  REINFORCEMENT/LOSSES  CARD. 

FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  and  syntax  of  input  after  REINFORCEMENTA.OSSES  card  in 
runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  RENIN. 

123)  **  ERROR-123  **  FORMAT  ERROR  AFTER  REPLICATIONS  CARD. 

a)  Check  format  of  input  after  REPLICATIONS  card  in  runstream. 

b)  See  input  manual  for  proper  format. 
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c)  See  subroutine  RERUN. 

124)  **  ERROR-124  **  FORMAT  ERROR  IN  SHIELDING  INPUT  FOR _ . 

FAULTY  CARD.  [  J. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  of  SHIELDING  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  SHLDIN. 

125)  **  ERROR-125  **  FORMAT  ERROR  IN  TLE.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  (rackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  of  TLE  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  TLEIN. 

126)  **  ERROR-126  **  FORMAT  ERROR  ON  INPUT  OF  VOLLEY.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  of  VOLLEY  input  in  runstream. 

d)  See  input  manual  for  proper  format. 

e)  See  subroutine  VLLYIN. 

127)  **  ERROR-127  **  FORMAT  ERROR  AFTER  WIND  DIRECTION  CARD.  FAULTY  CARD. 

[  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  format  of  WIND  DIRECTION  input  in  runstream. 
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d)  See  input  manual  for  proper  forrnat. 

e)  See  subroutine  WINDIN. 

128)  **  ERROR-128  **  FOUND  AN  ILLEGAL  DEGRADATION  CODE  IN  SUBROUTINE 

DGDSTM. 

a)  See  SUBLETHAL  DOSE  DEGRADATION  input  in  the  input  manual  for  correct  format 
of  code  numbers. 

b)  See  subroutine  DGDSTM. 

129)  **  ERROR-129  **  INPUT  ERROR,  FAULTY  CARD  [  ]  DETECTED  ON  INPUT  OF 

DATA  FOR  WEAPON  VS.  TARGET 


a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 

c)  Check  runstream  for  correct  format  and  syntax  under  input  data  for  specified  weapon. 

d)  See  subroutine  CONVIN. 

130)  **ERROR-130**  INPUT  ERROR  AFTER  CARD  ON  OR  BEFORE  CARD 

/ 

a)  Check  format  and  syntax  of  input  in  runstream. 

b)  See  subroutine  ENCIN. 

131)  **  ERROR-131  **  INCORRECT  NO.  OF  REAL  NUMBERS  ON  FAILURE  FOR _ . 

a)  Check  for  correct  number  of  reals  on  FAILURE  input. 

b)  See  input  manual  for  proper  format. 

c)  See  subroutine  FAILIN. 

132)  **  ERROR-132  **  INPUT  ERROR.  FAULTY  CARD.  [  ]. 

a)  Line  of  input  with  error  will  be  output  in  brackets. 

b)  See  line  of  input  where  error  occurred. 
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c)  Check  format  and  syntax  of  input  in  runstream. 

d)  See  input  manuai  for  proper  format. 

e)  See  subroutine  NUCIN. 

133)  **  ERROR-133  **  LINK _  IS  NOT  DEPLOYED.  ASSETS  IN  LINK  CANNOT 

TAKE  CASUALITIESM! 

a)  Location  of  link  must  be  defined.  Assets  will  fill  into  tasks,  but  kills  against  these 
assets  cannot  be  assessed  unless  link  is  deployed. 

b)  Verify  LINKS  and  DEPLOYMENT  section  of  runstream. 

c)  See  subroutine  LNKCHK. 

134)  **  ERROR-134  **  LETHALITY  DATA  EXCEEDS  STORAGE.  STOP  IN  TOXIN. 

a)  Combine  lethality  data  or  redimension  array  RA. 

b)  See  subroutine  TOXIN. 

135)  *•  ERROR-135  **  LETHALITY  DATA  TYPE  1  NOT  ALLOWED,  REQUESTED  FOR 

WEAPON  _  ON  ASSET _ 

a)  Data  type  one  is  currently  not  allowed.  Change  lethality  input. 

b)  See  AURA  Volume  I  for  currently  available  lethality  data  types. 

c)  See  subroutine  CONVIN. 

136)  **  ERROR-136  **  MAXIMUM  NUMBER  OF  LINKS  (@LNK)  EXCEEDED. 

a)  Reduce  number  of  links  to  less  than  (@LNK)  or  redimension  code. 

b)  See  subroutine  DEPLIN. 

137)  •*  ERROR-137  **  MUST  INPUT  KILL  CRITERION  FOR  TARGET  POINT. 

a)  Kill  criteria  can  only  be  input  as  an  integer  with  a  value  of  1-20.  Check  lethality  file 
for  ^}propriate  level  of  kill  criteria  for  target  point  and  input  on  DEPLOYMENT  card(s). 
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b)  See  subroutine  DEPLIN. 


138)  **  ERROR-138  **  MUST  INPUT  LINKS  BEFORE  METABOLIC  RATES. 

a)  Check  order  of  input  in  runstream.  Place  links  before  metabolic  rates. 

b)  Check  link  names  and  heat  stress  input  for  possible  typographical  error. 

c)  See  subroutine  HTSTIN. 

139)  **  ERROR-139  **  MUST  START  NAMES  INPUT  WITH  WEAPON  OR  ASSETS  CARD. 

a)  Check  syntax  of  runstream.  WEAPON  or  ASSET  card  must  be  the  first  non  comment 
card  after  NAMES. 

b)  See  input  manual  for  proper  format. 

c)  See  subroutine  NAMES. 

140)  **  ERROR-1 40  **  MUST  INPUT  LINKS  BEFORE  ORLINKS.  STOP  IN  ORLIN. 

a)  Check  order  Input  in  runstream.  Place  links  before  orlinks  In  runstream. 

b)  See  subroutine  ORLIN. 

141)  **  ERROR-141  *•  NO  CONVENTIONAL  LETHALITY  DATA  FOR  WEAPON  NUMBER 

ON  ASSET  WITH  COVER  TYPE  AND  KILL  CRITERION 


a)  Verify  weapon  name  and  check  for  missing  lethality  data.  Also,  verify  posture  types 
and  kill  criterion. 

b)  See  subroutine  CNVDMG. 

142)  **  ERROR-142  **  NUMBER  OF  COMPOUND  LINKS  EXCEEDS  STORAGE. 

a)  Maximum  number  of  compound  links  allowed  is  21.  Reduce  the  number  of  compound 
links  or  redimension  code. 

b)  See  subroutine  CPLKIN. 
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143)  **  ERROR-143  **  NUMBER  OF  SECONDARIES  EXCEEDS  STORAGE.  STOP  IN 

DEP2ND. 

a)  Maximum  number  of  secondaries  allowed  is  103.  Reduce  the  number  of  secondary 
explosions  to  less  than  103  or  redimension  code. 

b)  See  subroutine  DEP2ND. 

144)  **  ERROR-144  **  NUMBER  OF  TARGET  POINTS  EXCEEDED  WHILE  EXTENDING 

FOR  SECONDARY  EXPLOSION  SOURCES.  STOP  IN  DEP2ND. 

a)  Reduce  the  number  of  target  points,  especially  secondary  explosives. 

b)  See  subroutine  DEP2ND. 

145)  **  ERROR-145  **  NUMBER  OF  RECONSTITUTIONS  EXCEEDS  STORAGE _ .  MAX 

=  (@TIM). 

a)  Reduce  the  number  of  reconstitutions  times  to  less  than  (@TIM)  or  redimension  code. 

b)  See  subroutine  EVNCHK. 

146)  **  ERROR-146  **  NUMBER  OF  POSSIBLE  SURVIVORS  BY  TARGET  POINT 

EXCEEDS  STORAGE  IN  RA.  STOP  IN  NDXSET. 

a)  Reduce  the  number  of  assets  deployed  or  redimension  #RA. 

b)  See  subroutine  NDXSET. 

147)  **  ERROR-147  **  NUCLEAR  LETHALITY  DATA  HAS  SUSPICIOUSLY  LOW  SIGMA 

FOR  ASSET  TYPE _ 

a)  Nuclear  lethality  data  sigma  must  be  greater  than  0.001 . 

b)  Check  nuclear  vulnerability  file. 

c)  See  subroutine  NUCIN. 

148)  **  ERROR-148  **  NUMBER  OF  WEAPONS  HAVING  COMMON  NAME _  EXCEEDS 

TEMPORARY  STORAGE  IN  CONVIN. 
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a)  Reduce  number  of  weapons  with  common  name  or  redimension  code. 

b)  See  subroutine  CONViN. 

149)  **  ERROR-149  **  NUMBER  OF  CONVENTiONAL  LETHALITY  TYPES  EXCEEDS  MAX 

(20). 

a)  Reduce  the  number  of  conventional  lethality  types  to  less  than  20. 

b)  A  conventional  lethality  type  is  defined  by  a  weapon  name  in  the  conventional  lethality 
data  file.  See  Appendix  B  in  AURA  Volume  2. 

c)  See  subroutine  CONVIN. 

150)  **  ERROR-1 50  **  NUMBER  OF  PARAMETERS _ NOT  CORRECT  FOR  DATA  TYPE 

_ .  CONVENTIONAL  LETHALITY  DATA  ERROR  ON  WEAPON 

VS.  ID 


a)  Check  conventional  lethality  file  for  correct  format  and  syntax  of  input  data. 

b)  See  subroutine  CONVIN. 

151)  **  ERROR-151  **  NUMBER  OF  TARGETS  EXCEEDS  ALLOTTED  STORAGE  = _ 

a)  Reduce  number  of  targets  or  redimension  code. 

b)  See  subroutine  DEPLIN. 

152)  **  ERROR-152  **  NUMBER  OF  EVENTS  EXCEED  STORAGE _ .  STOP  IN 

EVNTBL.  MAX  =  (@NEV). 

a)  Reduce  the  number  of  events  allowed  to  less  than  (@NEV)  or  redimension  code. 

b)  See  subroutine  EVNTBL. 

153)  **  ERROR-153  **  NUMBER  OF  TOXIC  ROUNDS  AWAITING  PROCESSING _ 

EXCEEDS  STORAGE.  STOP  IN  LETHAL. 
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a)  Reduce  the  number  of  chemical  rounds  or  spread  them  out  in  time  or  redimension 
code. 

b)  See  subroutine  LETHAL 

154)  **  ERROR-154  **  NUMBER  OF  LINKS  EXCEEDS  MAX _ .  STOP  IN  LNKIN. 

a)  Reduce  the  number  of  links  to  less  than  (@LNK)  or  redimension  code. 

b)  See  subroutine  LNKIN. 

155)  **  ERROR-155  **  NUMBER  OF  PARAMETERS _ NOT  CORRECT  FOR  DATA  TYPE 

_ .  NUCLEAR  VULNERABILITY  ERROR  FOR  ASSET _ 

a)  Check  syntax  for  nuclear  vulnerability  input. 

b)  See  subroutine  NUCIN. 

156)  **  ERROR-156  **  NUMBER  OF  TOXIC  WEAPON  TYPES  EXCEEDS  STORAGE.  MAX  = 

(@TW). 

a)  Reduce  the  number  of  toxic  weapon  types  to  less  than  (@TW)  or  redimension  code. 

b)  See  subroutine  TOXIN. 

157)  **  ERROR-157  **  NUMBER  OF  VOLLEYS  EXCEEDS  STORAGE.  STOP  CALLED 

FROM  VOLLEY. 

a)  Reduce  the  number  of  volleys  or  redimension  code. 

b)  See  subroutine  VLLYIN. 

158)  **  ERROR-158  **  ONLY  @NAP  TLE  CHANGES  ALLOWED.  STOP  IN  TLE  INPUT. 

a)  Reduce  the  number  of  target  location  error  change  events  to  less  than  (@NAP)  or 
redimension  code. 

b)  See  subroutine  TLEIN. 
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159)  **  ERROR-159  **  PROBABLE  ERROR  IN  LINK  INPUT.  NAME _ BEGINS  WITH  A 

SPECIAL  CHARACTER  (=,*.+,!). 

a)  Verify  syntax  of  link  input  in  runstream.  Possible  typo. 

b)  Link  name  may  not  begin  with  special  character. 

c)  See  subroutine  LNKIN. 

160)  **  ERROR-160  **  NUMBER  OF  SUBSTITUTES  EXCEEDS  STORAGE _ MAX  = 

(@NSB).  STOP  CALLED  FROM  ENCSET. 

a)  Reduce  the  number  of  substitutes  to  less  than  (@NSB)  or  redimension  code. 

b)  See  subroutine  ENCSET. 

161)  **  ERROR-161  •*  REPAIR  DATA  MUST  BE  INCLUSIVE!  STOP  IN  LETHAL 

a)  Probability  of  light  damage  >  medium  damage  >  heavy  damage  for  all  miss  distances. 

b)  See  AURA  Volume  1 . 

c)  See  subroutine  CNVLTH, 

162)  **  ERROR-162  **  SECONDARY  EXPLOSION  ASSET  MUST  BE  NAMED  IN  BOTH 

ASSET  AND  WEAPON  INPUTS. 

a)  Check  ASSET  and  WEAPON  cards  for  secondary  explosion  name.  Primary  name  of 
secondary  explosive  must  appear  under  both. 

b)  See  subroutine  SCNDIN. 

163)  **  ERROR-163  **  SOMETHING  WRONG  IN  REPAIR.  CLEAR  BEFORE  OPTMIZ 

DIAGNOSTIC.  STOP  IN  OPTMIZ. 

a)  Internal  code  error.  Contact  Code  Custodian. 

b)  See  subroutine  OPTMIZ. 
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164)  **  ERROR-164  **  SORRY!  TOXIC  DISSEMINATION  DATA  MUST  BE  READ  IN 

BEFORE  ALARMS.  THE  CODE  FOUND  NO  VAPOR 
NORMALIZATION  FOR  WEAPON _ . 

a)  Check  that  toxic  dissemination  data  was  input  correctly  and  was  listed  in  runstream 
before  the  ALARM  mnemonic  card. 

b)  See  subroutine  ALRMIN. 

165)  **  ERROR-165  **  STORAGE  EXCEEDED  FOR  CHAINS.  STOP  IN  CHAIN  INPUT 

ROUTINE. 

a)  Maximum  number  of  chains  allowed  is  six.  Reduce  number  of  chains  or  redimension 
code. 

b)  See  subroutine  CHNIN. 

166)  **  ERROR-166  **  STORAGE  (@RA)  EXCEEDED  IN  LARGE  MASTER  ARRAY. 

a)  Reduce  conventional  lethality  data. 

b)  Redimension  code. 

c)  See  subroutine  CONVIN. 

167)  **  ERROR-167  **  STORAGE  FOR  COMPOUND  LINK  PARTS _ EXCEEDED. 

MAX  =  (@NCP). 

a)  Reduce  the  number  of  compound  link  parts  to  less  than  (@NCP)  or  redimension  code. 

b)  See  subroutine  CPLKIN. 

168)  **  ERROR-168  **  STORAGE  FOR  SUBSTITUTES  EXCEEDED.  REDIMENSION  RA 

AND  MDX(3)  (MD3).  STOP  IN  ENCSET. 

a)  Reduce  the  number  of  substitutes  or  redimension  code. 

b)  See  subroutine  LNKSET. 
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169)  **  ERROR-169  *•  STORAGE  EXCEEDED  FOR  ORLINKS.  STOP  IN  ORLINK  INPUT 

ROUTINE. 


a)  Reduce  the  number  of  orlinks  to  less  than  (@ORL)  or  redimension  code. 

b)  See  subroutine  ORLIN. 

170)  **  ERROR-1 70  **  STORAGE  EXCEEDED  FOR  SUBCHAINS.  STOP  IN  SUBCHAIN 

INPUT  ROUTINE. 

a)  Reduce  the  number  of  subchains  to  less  than  (@SCH)  or  redimension  code. 

b)  See  subroutine  SBCIN. 

171)  **  ERROR-171  **  SUBCHAIN _ .  EXCEEDS  MAXIMUM  LINKS  (  _  ).  USE  MORE 

SUBCHAINS  OR  REDIMENSION  TEMPORARY  STORAGE  IN 
SBCOPT. 

a)  Only  27  links  allowed  in  any  one  subchain. 

b)  Change  structure  or  redimension  SBCOPT  and  SBCIN. 

c)  See  subroutine  SBCIN. 

172)  **  ERROR-172  **  TEMPORARY  STORAGE  FOR  SEGMENTS  (  _  )  EXCEEDED  IN 

OPTMIZ  NEED  FOR  CHAIN  REPAIR  LINKS. 

a)  Reduce  number  of  segments  in  chain  to  less  than  94  or  redimension  code. 

b)  See  subroutine  OPTMIZ. 

173)  **  ERROR-173  **  TOO  MANY  ASSETS  IDENTIFIED  AS  ALARMS  (5  MAX). 

a)  Reduce  number  of  unique  assets  identified  as  alarms  to  five  or  less. 

b)  Redimension  code. 

c)  See  subroutine  ALRMIN. 
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174)  **  ERROR-174  **  TOO  MANY  TIME  INTERVALS  FOR  CHAIN _ 

a)  Reduce  the  number  of  time  inten/als  to  less  than  17  or  redimension  code. 

b)  See  subroutine  CHNIN. 

175)  **  ERROR-175  **  TOO  MANY  DELIVERY  ERROR  EVENTS. 

a)  Reduce  the  number  of  delivery  errors  to  less  than  193  or  redimension  code. 

b)  See  subroutine  DLVRIN. 

176)  **  ERROR-176  **  TOO  MANY  INCOMING  FIRE  DIRECTION  CHANGES.  STOP  IN 

INCIN. 

a)  Reduce  the  number  of  incoming  fire  directions  to  less  than  21  or  redimension  code. 

b)  See  subroutine  INCIN. 

177) **  ERROR-1 77  “TOO  MANY  ALARMS  DEPLOYED.  MAX  =  (@NAR).  STOP  IN 

TGTSET. 

a)  Reduce  the  number  of  alarms  to  less  than  (@NAR)  or  redimension  code. 

b)  See  subroutine  TGTSET. 

178)  **  ERROR-178  **  TOP  OF  MEMORY  (ARRAY  RA)  EXCEEDED  BY  EXPANDING  DOSE 

BINS.  STOP  IN  ROUTINE  CUMDOS.  MAY  SOLVE  PROBLEM  BY 
TURNING  INDIVIDUAL  DOSE  OFF  (UNDER  MODE). 

a)  Try  turning  INDIVIDUAL  DOSE  off  (under  MODE  mnemonic  card).  If  this  does  not 
work,  contact  Code  Custodian. 

b)  Redimension  code. 

c)  See  subroutine  CUMDOS. 

179)  **  ERROR-179  **  TROUBLE.  NUCLEAR  LETHALITY  DATA  OVERFLOWS  TOP  OF 

MEMORY.  STOP  IN  NUCIN. 
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a)  Reduce  amount  of  input  data  (size  of  unit,  etc.)- 

b)  Redimension  code. 

c)  See  subroutine  NUCIN. 

180)  **  ERROR-1 80  **  WEAPON  NAME  DOES  NOT  APPEAR  ON  WEAPON  NAME  LIST. 

a)  Check  for  typo  in  weapon  name  list  and  weapon  characteristic  inputs. 

b)  See  subroutine  DLVRIN. 
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Intentionally  left  blank. 
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No.  of 
Copies 

2 

1 

1 

2 

2 

1 

icIaM.  only)^ 

1 


Organization 


No.  of 

Copies  Organization 


Administrator 

Defense  Technical  Info  Center 
ATTN:  DTIC-DDA 
Cameron  Station 
Alexandria,  VA  22304-6145 


Commander 

U.S.  Army  Tank-Automotive  Command 
ATTN:  ASQNC-TaC-DIT  (Technical 
Information  Center) 

Warren,  Ml  48397-5000 


Commander  1 

U.S.  Army  Materiel  Command 
ATTN:  AMCAM 
5001  Eisenhower  Ave. 

Alexandria,  VA  22333-0001 

1 

Commander 

U.S.  Army  Laboratory  Command 
ATTN:  AMSLC-DL 
2800  Powder  Mill  Rd. 

Adelphi,  MD  20783-1145  2 

Commander 

U.S.  Army  Armament  Research, 

Development,  and  Engineering  Center 
ATTN:  SMCAR-IMI-I  (CtaM.oniyn 

Picatinny  Arsenal,  NJ  07806-5000 

Commander 

U.S.  Army  Armament  Research, 

Development,  and  Engineering  Center  (Unciat*.  oniy)-j 
ATTN:  SMCAR-TDC 
Picatinny  Arsenal,  NJ  07806-5000 

Director 

Benet  Weapons  Laboratory  1 

U.S.  Army  Armament  Research, 

Development,  and  Engineering  Center 
ATTN:  SMCAR-CCB-TL 
Watervliet,  NY  12189-4050 

2 

Commander 

U.S.  Army  Armament,  Munitions, 
and  Chemical  Command 

ATTN:  AMSMC-IMF-L  1 

Rock  Island.  IL  61299-5000 


Director 

U.S.  Army  TRADOC  Analysis  Command 
ATTN:  ATRC-WSR 

White  Sands  Missile  Range,  NM  88002-5502 
Commandant 

U.S.  Army  Field  Artillery  School 

ATTN:  ATSF-CSl 

Ft.  Sill,  OK  73503-5000 

Commandant 
U.S.  Army  Infantry  School 
ATTN:  ATZB-SC,  System  Safety 
Fort  Benning,  GA  31903-5000 

Commandant 

U.S.  Army  Infantry  School 

ATTN:  ATSH-CD  (Security  Mgr.) 

Fort  Benning,  GA  31905-5660 

Commandant 
U.S.  Army  Infantry  School 
ATTN:  ATSH-CD-CSO-OR 
Fort  Benning,  GA  31905-5660 

WL/MNME 

Eglin  AFB,  FL  32542-5000 

Aberdeen  Proving  Ground 

Dir,  USAMSAA 
ATTN:  AMXSY-D 

AMXSY-MP.  H.  Cohen 

Cdr,  USATECOM 
ATTN:  AMSTE-TC 


Director 

U.S.  Army  Aviation  Research 
and  Technology  Activity 
ATTN:  SAVRT-R  (Library) 

M/S  219-3 

Ames  Research  Center 
Moffett  Field.  CA  94035-1000 

Commander 

U.S.  Army  Missile  Command 
ATTN:  AMSMI-RD-CS-R  (DOC) 
Redstone  Arsenal,  AL  35898-5010 


3  Cdr,  CRDEC,  AMCCOM 
ATTN:  SMCCR-RSP-A 
SMCCR-MU 
SMCCR-MSI 

1  Dir.  VLAMO 

ATTN:  AMSLC-VL-D 

10  Dir,  USABRL 

ATTN:  SLCBR-DD-T 
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No.  of 

Copies  Organization 

1  HQDA 
OASA  (RDA) 

ATTN:  SARD-DOS,  MAJ  Gary  R.  Davis 
WASH  DC  20310-0103 

10  C.LA 

ATTN:  OIR/DB/Standard 
GE-47  HQ 

Washington,  DC  20505 

2  Director 

Defense  Nudear  Agency 
ATTN:  STBE. 

Dr.  D.  Auton 
Dr.  R.  Young 
Washington,  DC  20305 

2  Commander 

Defense  Nuclear  Agency/Field  Command 
ATTN:  FCPR, 

MAJ  Fleming 
CPT  Thorton 
Kirtland  AFB,  NM  87115 

2  DA/ODCSOPS 
Pentagon 

ATTN:  DAMO-ZXG,  Mr.  Patterson 

DAMO-ZDS.  LTC  Michael  Whitaker 
Washington,  DC  20310-0404 

1  Commander 

U.S.  Army  Materiel  Command 
ATTN:  AMCDRA-AT 
5001  Eisenhower  Avenue 
Alexandria,  VA  22333-0001 

4  Commander 

U.S.  Army  Armament  Research, 
Development,  and  Engineering  Center 
ATTN:  SMCAR-FSS. 

Mr.  Ostuni 
Mr.  Brooks 
SMCAR-TSS 
SMCAR-TDC 

Picatinny  Arsenal,  NJ  07806-5000 


No.  of 

Copies  Organization 

1  CDR 

CATA-NSC 

ATTN:  ATZL-TAC-DC,  CPT  H.  Lee 
Ft.  Leavenworth,  KS  66027 

1  Commander 
HQ  AMCCOM 
ATTN:  AMSMC-IMP-IL 
Rock  Island,  IL  61299-7300 

1  Commander,  USACECOM 
R&D  Technical  Library 

ATTN:  ASQNC-ELC-IS-L-R,  Myer  Center 
Fort  Monmouth,  NJ  07703-5000 

5  Commander 

U.S.  Army  Harry  Diamond  Laboratories 
ATTN:  SLCHD-NW-RA 
2800  Powder  Mill  Road 
Adelphia,  MD  20783 

2  Director 

U.S.  Army  Missile  and  Space  Intelligence 
Center 

ATTN:  AIAMS-YDL 
AIAMS-TSL 

Redstone  Arsenal,  AL  35898-5500 

1  Commander 

U.S.  Army  Missile  Command 
ATTN:  AMSMl-OR-RS-SM, 

Joseph  Nordman 
Redstone  Arsenal,  AL  35898 

1  Commander 

U.S.  Army  Program  Executive  Office, 

Air  Defense 

ATTN:  SFAE-AD-PA-ATM, 

LTC  Roy  D.  Miller 
Redstone  Arsenal,  AL  35898 

2  Commander 
TRAC-WSMR 

ATTN:  ATRC-WSR,  Mr.  Belk 
ATOR-TSL 

White  Sands  Missile  Range,  NM  88002-5522 
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Director 

TRAC-FLVN 

ATTN:  ATRC-FTC.  CRT  Perry 

ATRC-F,  Robert  LaRocque 
Ft.  Leavenworth,  Kb  66027 

Director 
TRAC  RPD 

ATTN:  ATRC-RPR.  Mr.  Radda 
Ft.  Monroe.  VA  23651-5143 

Commander 

U.S.  Army  Aviation  Logistics  Center 
ATTN:  ATSP-CD, 

CPT  White 
Mr.  Pollack 
Ft.  Eustls,  VA  23604 

Commander 

U.S.  Army  Combined  Arms  Combat 
Developments  Agency 
ATTN:  ATZL-CAS-SP,  CPT  DeWulf 
ATZL-CAP, 

COL  Henderson 
CPT  Grand 

Ft.  Leavenworth,  KS  66027 

U.S.  Army  Nuclear  and  Chemical  Agency 
ATTN:  MONA-WE 

MONA-CM,  MAJ  Joe  Fernandez 
MONA-NU,  David  Bash 
7500  Backlick  Road,  BkJg  2073 
Springfield,  VA  22150-3198 

Director 
TRAC-Ft.  Lee 
ATTN:  ATRC-OS 
Ft.  Lee,  VA  23801-6000 

Director 

Concepts  Analysis  Agency 
ATTN:  CSCA-SPN, 

P'4us  C.  Ling 
Robert  W.  Barrett 
CSCA, 

Mr.  D.  Hurd 
LTC  Barrett 
Mr.  Chandler 
8120  Woodmont  Avenue 
Bethesda.  MD  20014 
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U.S.  Army  Model  Improvement  and 
Study  Management  Agency 
ATTN:  SFUS-MIS,  Eugene  P.  Visco 
1900  Half  Street,  SW;  RM  LI  01 
Washington,  DC  20324 

1  Commandant 

U.S.  Army  Air  Defense  Artillery  School 

ATTN:  ATZK-CD 

Bldg5800 

Ft.  Bliss,  TX  79916 

1  Commander 

U.S.  Army  Engineering  School 

ATTN:  ATSE-CDM 

Ft.  Leonard  Wood,  MO  65473-6620 

1  Commander 

U.S.  Army  Field  Artillery  School 
ATTN:  ATSF-CD 
Ft.  Sill,  OK  73503 

1  Commandant 

U.S.  Army  Transportation  School 
ATTN:  ATSP-PD-C 
Ft.  Eustis,  VA  23604 

2  Commander 

U.S.  Army  Missile  and  Munitions  Center 
and  School 

ATTN:  ATSK-CD  (2  cps) 

Redstone  Arsenal,  AL  35898 

1  Commander 

U.S.  Army  Quartermaster  School 
ATTN:  ATSM-CDC 
Ft.  Lee,  VA  23801 

1  Commander 

U.S.  Army  Signal  Center  &  School 
Directorate  of  Combat  Developments 
Ft.  Gordon,  GA  30905 
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4  Commandant 

U.S.  Amny  Chemical  School  Directorate 
of  Combat  Developments 
ATTN:  ATZN-CM-CC, 

LTC  Gary  Stratton 
Mr.  B.  Gould 
Ms.  Sherry  Barnes 
Ms.  Rena  Seals 
Ft.  McClellan,  AL  36201 
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Commander 

Armed  Forces  Radiobiological  Research 
Institute 

National  Naval  Medical  Center 
ATTN:  Mr.  William  Jackson 
Bethesda,  MD  20014 


2  Commander 

Combined  Arms  Center 
Scores  Working  Group 
ATTN:  AT2L-CAD-LN  (2  cps) 
Ft.  Leavenworth,  KS  66027 
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4  U.S.  Army  Personnel  Command 

ATTN:  DAPC-MOP,  H.  Rowland  Ludden 
TAPC-MOP, 

MAJ  M.  Brice  Elliot 
MAJ  Mike  O'Donnell 
CPT  I.  McMahon 
200  Stovall  Street 
Alexandria,  VA  22332-0432 


1  U.S.  Army  Chief  of  Staff 
ATTN:  DACS-DPZ-A 
The  Pentagon 
Washington,  DC  20310 


3  U.S.  Army  Deputy  Chief  of  Staff 
for  Operations  and  Plans 
ATfN:  DAMO-SWC,  LTC  Gordon  Miller 
DAMO-ZD, 

Mr.  John  Riente 
Mr.  James  Metzger 
The  Pentagon 
Washington,  DC  20310 


2  Commander 

Naval  Surface  Warfare  Center 
ATTN:  Code  31, 

Mr.  Tom  Yencha 
Mr.  P.  Kirk 
Dahlgren,  VA  22448 

1  President 

Center  for  Naval  Analyses 
4401  Ford  Avenue 
P.O.  Box  16268 
Alexandria,  VA  22302-0268 

2  Walter  Reed  Army  Institute  of  Research 
Division  of  Medicine 

Department  of  Respiratory  Research 
ATTN:  SGRD-UWH-E, 

MAJ  Gary  R.  Ripple,  MD 
LTC  Kenneth  Torrington 
Washington,  DC  20307-5100 

3  Institute  for  Defense  Analysis 
ATTN:  Mr.  Graham  McBryde 

Mr.  M.  Kerlin 
Dr.  M.  Charren 
1801  N.  Beauregard  Street 
Alexandria.  VA  22311 


1  Headquarters 
Defense  Nuclear  Agency 

ATTN:  RARP,  MAJ  Robert  Kehlet 
6801  Telegraph  Road 
Alexandria.  VA  22310  -3398 

2  Office  of  the  Surgeon  General 
ATTN:  DASG-HCO-P.  MAJ  Ray  Keith 

DASG-HCD.  MAJ  Robert  Eng 
5111  Leesburg  Pike 
Falls  Church.  VA  22041 

1  Office  of  the  Surgeon  General 
ATTN:  MAJ  William  J.  Klenke 
5109  Leesburg  Pike 
Falls  Church.  VA  22041 

1  U.S  Army  Engineer  Studies  Center 
ATTN:  ESC-EO 
Casey  Bldg  2594 
Ft.  Belvoir,  VA  22060-5583 
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Commanding  General 
U.S.  Army  Operational  Test  and 
Evaluation  Agency 
Park  Center  IV 
4501  Ford  Avenue 
Alexandria,  VA  22302-1428 

Director 

TRAC-MTRY 

Naval  Postgraduate  School 

ATTN:  LTC  Vernon  M.  Bettencourt,  Jr. 

MAJ  R.  Wimberley 
P.O.  Box  8692 
Monterey,  CA  93943-0692 

U.S.  Army  Command  and  General 
Staff  College 

Office  of  the  Commandant 
Ft.  Leavenworth,  KS  66027-6900 

EAI  Corporation 
ATTN:  Mr.  Dennis  Metz 
Mr.  Bruce  Fischer 
Mr.  S.  Matthew  Hutton 
1308  Continental  Drive,  Suite  J 
Abingdon,  MD  21009 

Science  Applications  International 
Corporation 
ATTN:  R.  McNally 
M.  Stark 

626  Towne  Center  Dr. 

Joppa,  MD  21085 

Battelle 

ATTN:  D.W.  Harper 
7501  Memorial  Parkway  South 
Suite  101 

Huntsville,  AL  35802-2258 

WRDC/FIVS/SURVIAC 
Wright-Patterson  AFB,  OH  45433-6553 
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Aberdeen  Proving  Ground 

6  Dir,  USAMSAA 
ATTN:  AMXSY, 

Mr.  M.  Miller 
Ms.  C.  Horley 
Ms.  D.  Smoot 
AMXSY-C,  M.  Carroll 
AMXSY-G,  M.  Sandmeyer 
AMXSY-J,  R.  Mezan 

8  Cdr,  CRDEC,  AMCCOM 
ATTN:  AMSTE-SI-F 
SMCCR-ST, 

Mr.  D.  Sloop 
Mr.  R.  Jablonski 
Mr.  J.  Razulis 
Mr.  J.  Walther 
Mr.  C.  Crawford 
Mr.  L.  Davis 
Mr.  L.  Baer 

2  Cdr,  USAHEL 

ATTN:  W.  DeBellis 
O.  Zubal 

1  Cdr,  USAOC&S 

ATTN:  ATSL-CD-CS 
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USER  EVALUATION  SHEET/CHANGE  OF  ADDRESS 


This  laboratory  undertakes  a  continuing  effort  to  improve  the  quality  of  the  reports  it 
publishes.  Your  comments/answers  below  will  aid  us  in  our  efforts. 

1 .  Does  this  report  satisfy  a  need?  (Comment  on  purpose,  related  project,  or  other  area  of 
interest  for  which  the  report  will  be  used.)  _ 


2.  How,  specifically,  is  the  report  being  used?  (Information  source,  design  data,  procedure, 
source  of  ideas,  etc.)  _ 


3.  Has  the  information  in  this  report  led  to  any  quantitative  savings  as  far  as  man-hours  or 
dollars  saved,  operating  costs  avoided,  or  efteiencies  achieved,  etc?  If  so,  please 
elaborate.  _ 


4.  General  Comments.  What  do  you  think  should  be  changed  to  improve  future  reports? 
(Indicate  changes  to  organization,  technical  content,  format,  etc.)  _ 
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